After posting two entries about some custom SVK commands, it seems SVK had already beat me to the punch.

If you recall, I originally wrote the mymerge and mergeproject commands because I was tired of typing this out every time I needed to merge local changes up to the main repository:

svk smerge -I //$project_name/local //$project_name/main

As it turns out, SVK already has a command to do this — and in a more flexible way, to boot: push, an smerge macro like mine.

push takes a single argument, the thing to push changes from. This thing can be either a working copy or a depot path (if you don’t supply this argument, the current directory is used). In either case, SVK will automatically figure out the target for the merge:

  • If you supply a working path, SVK will first figure out which depot path you used when checking out the working copy, then…

  • If you supply a depot path (or if you’ve fallen through from above), SVK will figure out where you copied the depot path from, then merge to that parent path. (Note that it’s meaningless to use push on a mirrored path; svk push should only be used on depot paths copied from somewhere else.)

Once SVK has figured out the source and target paths, it will perform an incremental smerge. Hmm…this sounds suspiciously like my commands!

So, to translate my own commands into svk push:

svk mymerge $project_name

is the same as

svk push //$project_name/local

while

svk mergeproject

is the same as

svk push

Unfortunately, push’s entry in the SVK book can be summed up as “TODO”, the word that dominates the page. I’ve added this to my todo list, but it’s a fairly low priority at the moment.

In a future entry, I’ll talk about svk pull, the handy-dandy, already-written spelling of another custom command I was close to writing.