Work

I was not impressed when I tried to check out a UTF-8 encoded file with SVK, then got the helpful message Can't encode path as ascii:

$ svk up
Syncing //drp/trunk(/drp/trunk) in /home/wolever/Trunk to 5388.
Can't encode path as ascii.

I was even less impressed when I searched Google for svk unicode and this blog was the first hit.

Fortunately my Google-foo is high today, and I was able to find a page that gives a solution: Making sure that your locale is set to something similar to en_US.UTF-8.

On Debian, here's how I do it:

$ sudo apt-get install locales # Ubuntu 6.06 didn't have it...
...
$ export LANG="en_US.UTF-8"
$ export LANGUAGE="$LANG"

And, of course, it may be good to put those two exports in ~/.bashrc.

Oh, but wait!

$ svk up
Syncing //drp/trunk(/drp/trunk) in /home/wolever/Trunk to 5388.
Can't encode path as ascii.

It still doesn't work!

It turns out that, for what ever reason, something was upset. Eventually I got it working by deleting the offending directory, then using svk revert to revert it:

$ rm -r hacking/
$ svk revert -R hacking
...
Reverted hacking/utf8_爱的

Hurra!

I got a fairly significant patch to DrProject today. I wanted to show it to the other developers so they could give it a look over. How'd I do it?

    $ patch -p0 < patch
    ... check that it works ...
    # Create a new branch for the patch
    $ svk cp //drp/trunk //drp/branches/patch -m "Created branch for patch"
    # Do an in-place switch of my repository (which takes about 2 seconds,
    # versus the minute or two it would take to check the entire tree out)
    $ svk switch //drp/branches/patch 
    # Because switch doesn't revert modified files, the changes are still here,
    # ready to be checked in
    $ svk ci -m "Checking in patched code"

Now they can use DrProject's fancy online changeset viewer, checkout the code for themselves, use svn diff... The list is endless.

Now that rocks SO much more than mailing around .diff files (and makes life happier when it comes time to pull it back into trunk).

SVK, despite some of it's shortcomings, has proved worthy of my use in the last couple of days. Here is a quick script which shows how I've been using it, and how it's rocked the pants off of SVN:

red = commands with SVN
blue = equivalent SVK commands
green = comment

# Mirror the DrP repository to //dpr
$ # No equivilent
$ svk mirror https://drproject.org/drproject/DrProject/ //drp/

# Create the tags branch
$ svn cp https://drproject.org/drproject/DrProject/tunk \
         https://drproject.org/drproject/DrProject/branches/tags
$ svk cp //drp/trunk //drp/branches/tags

# Check out the branch
$ svn co https://drproject.org/drproject/DrProject/branches/tags Tags
$ svk co //drp/branches/tags Tags

# Some changes are made to the tags branch

# Checkin those changes
$ svn ci -m "Made some changes to tags branch"
$ svk ci -m "Made some changes to tags branch"
# In this case, SVK is not being used in decentralized
# mode, so the changes will be pushed upstream to the
# SVN repository, just like the svn commit does.

# Changes have also been made to trunk.
# Time to merge those changes in.

# First, a merge with SVN:
$ svn log --stop-on-copy
# Look for either the last revision which trunk was merged
# You can't always use the base revision, otherwise conflicts
# may ensue.
$ svn merge -r $REV:HEAD https://drproject.org/drproject/DrProject/tunk .
# Hope that there are no trivial conflicts to sort out,
# then test and commit the merge. 
$ svn ci -m "Merged trunk into tags."

# And now, exactly the same operation with SVK:
$ svk pull
# ... changes are merged ...
$ 

I don't think I need to say any more

(Yes, I realize that there are tools like svnmerge.py which make SVN merges less painful... But that's one extra command to run. And you've still got those stinking .svn directories everywhere.)

If there is one thing that I've found universally confusing about version control systems, it's how to revert back to a previous revision, then move on from there. Conventional wisdom would dictate that svn up -r $OLD with some additional flag that says pretend that we're still at HEAD would do the trick... But, alas, there exists no such flag.

So, besides svn cat -r $OLD $FILE > $FILE, what's the best way to revert a file (or entire tree) to an older revision? Well, it turns out that merge is the tool you're looking for.

The trick is that you can diff backwards as well as forwards:

[wolever@thebes] ~/test_dr/All svn diff -r 2:1
Index: stuff
===================================================================
--- stuff       (revision 2)
+++ stuff       (revision 1)
@@ -1,4 +1,3 @@
 Let us endeavor so to live that when we come to die even the undertaker will be
 sorry.
                -- Mark Twain, "Pudd'nhead Wilson's Calendar"
-Increased knowledge will help you now.  Have mate's phone bugged.
Index: docs.html

Which means that merge will work both ways as well:

[wolever@thebes] ~/test_dr/All svn merge -r 2:1 stuff
U    stuff
[wolever@thebes] ~/test_dr/All svn ci -m "reverted changes" stuff
[wolever@thebes] ~/test_dr/All svn diff -r 1:3 stuff
[wolever@thebes] ~/test_dr/All

Of course, this will also work with the myriad of other version control tools out there. In fact, if you're still using SVN, reverting old changes is probably the least of your problems... At least compared to, say, merging different branches ^_^

But that's a post for another day -- I need to stop writing about merging and actually get on with, err, doing it...