Branching and Merging with SVK
Originally posted on a private mailing list.
Talking with a guy on #ledgersmb, I asked him about how well SVK and SVN worked together. I had previously used SVK for disconnected commits, but had not had the nerve to set up an SVK server.
It turns out, you don't need to set up a SVK server, per se, to take advantage of SVK's branching and merging.
To play with it, I set up a directory with a single file:
test/test.txt
And branched it with
svk cp test test-branch
If I modified test-branch/test.txt I can use svk push inside test-branch, and it will automerge back to test/test.txt
If I modified test/test.txt I can use svk pull inside test-branch and it will automerge modifications from test/
I had an svn client working with, and it was able to update the changes cleanly. I can use svn to do commits against each branches, and SVK handles that no problem. As far as the svn client is working, someone did branching/merging, no problem. This is made possible because SVK stores the merging information inside SVN's revision properties. That's why I don't need a special SVK server, just using SVK as a beefed up SVN client.
Now the next tricky thing was using svn cp test-branch test-svn-branch and playing with that. SVK still enters in merge tickets, but getting changes was no longer a simple svk update. I had to use svk pull at the parent directory to get it to update. For what I want to use this for, I will just have to remember to create branches using svk cp rather than svn cp.
Why bother with all of this stuff? The short time I worked for BankOne, I learned a neat method for releasing software. Changes flows from:
development -> testing -> qa -> production
When I first setup Subversion, I had attempted to do something like that. Commit changes to trunk, and have changes pushed upstream for testing (I skipped Q/A as that was done during testing), then to production. The problem is that Subversion's merging sucked. It sucked because it does not track merging changes.
Having played with this, I can now do something like:
(developer-1, developer-2, developer-3) -> trunk -> testing -> production
Pushing to testing and production would be a simple svk pull
Each developer has their own branches to isolate any potentially destructive changes. The developers do not necessarily need SVK (unless they are doing disconnected commits, such as if they are roaming around with a laptop like I do). This is a good thing, since TortoiseSVN is a known factor, and Windows may or may not play with SVK (written in Perl) very well.
The supervisor or PM would have commit priveledges to trunk, probably by using a different set of passwords, so he would do an svk push inside a developer branch once he makes sure it won't destroy anything. Lastly, all the changes, mistakes, whatever can get versioned, a habit I have similar to hitting "save" all the time. Nightly or continous builds would come off of trunk/testing.
Summary: SVK transparently makes merging as trivial as SVN branching without having to change anything server-side.