The svk patch feature can be a little confusing to newcomers. This page will attempt to boil its usage down to the essence.

(Caveat: This page itself was begun by such a newcomer. If you are a more experienced SVK user and you find inaccuracies, bad advice, etc., please edit this freely.)

Creating a patch from scratch

Whether you want to create a patch because you don't have commit access to a depot/repository or you just aren't sure your changes are ready for prime time, beginning the process is the same:

• Check out a working copy from a depot.
• Make your changes until you are satisfied with them.
• Use svk commit -P NAME to "commit" your changes to a new patch named NAME (of course you can use any name that is meaningful).

Do not svk commit your changes back to the depot, even if it is a branch you have made for yourself on your personal depot.

Syncing remote changes

Whenever you need to pull new upstream sources, do this:

• Use svk pull to update your working copy as usual.
• Then svk patch --update NAME immediately. Do this before you make any more changes!

Note that you do not have to be in your working directory when you update a patch. SVK remembers what to do (it makes notes to itself in the patch file).

Making more changes to your patch

When you make additional changes, do this instead of a commit:

• Did you make sure you have the latest upstream changes? If not, see the instructions above to do a pull.
• svk patch --regen NAME to combine your previous changes and newest changes into a new version of your patch.

If you want to make multiple patches, you should probably just check out as many separate working copies as you need for each patch. KISS.

Sticky issues

You may run into a situation where upstream changes appear to conflict with a patch you are working with. When this happens, updating the patch will fail (as in this example from a confused newbie):

$ svk patch --update meld-svk-support
C   vc/__init__.py
A   vc/svk.py
G   vc/svn.py
Empty merge.
Conflicts.
1 conflict found, update aborted.

Possible cause: You didn't heed the advice above never to commit your changes directly back to a depot, and something bad happened (probably upstream changes slipped into the patch by accident).

How to recover from this? One suggestion (if you can call it recovery):

• Examine the patch file directly (use svk patch --view or go directly into the patch subdirectory of your SVK directory).
• Copy it to a file.
• Edit out the SVK-specific data at the beginning and end.
• Edit out any changes you know came from upstream, leave in changes that you know are supposed to be part of the patch.
• Throw away your working copy and the SVK-managed patch file.
• Start at the top again from "Check out a working copy from a depot." Run your edited patch copy through patch -p0 to re-apply it to your working copy.
• Remember where you went wrong with committing your changes directly to the depot. And don't do it again! :-)