Part I of this article appeared some time ago — you can find it in the September posts. In this second section I describe what’s not quite right with Subversion (SVN) and what I like about SVK, it’s heir. I don’t have here a lot of info about how SVK came about and what not — see the SVK home page for details.
SVN is CVS done right, but SVK takes SVN one better. To use SVN you must be constantly in contact with the server that contains your repository, and must access it with a usually long URL that is easy to misspell. While this is less of a problem in the wireless, connected world we live in than it used to be, there are certainly places where you cannot easily link to the Internet, or there may be situations when you just want to save your laptop battery and inactivate your wireless card. With SVK, you don’t have to be connected to check in and check out files. SVK sets up a local repository on your hard drive that mirrors the central repository on your server. You can name this a short name, such as //epsimulator instead of //sluggo.epsimulator.com/var/lib/repositories/svn/epsimulator/trunk. You can then check out your files from the local repository, //epsimulator. If you check in changes, though, you must be connected to the server that contains the SVN repository that was mirrored. BUT … there is a slick way around that, as shown below.
The work flow for SVK goes something like this. Mirror your remote repository on your laptop, for example.
svk mirror http://sluggo.epstudiossoftware.com/var/lib/repositories/svn/epsimulator //epsimulator
You must get into the habit of synchronizing the local repository, to bring in any changes made by others. This is one extra step with SVK and easy to forget:
svk sync –all
Then checkout your files:
svk checkout //epsimulator
After checkout, you can update your files as long as you are in the sandbox directory:
svk update
Check in your changes:
svk commit -m ‘Here are my changes!’
Note the mandatory message to help keep track of what you did with each revision. With the commit, both the mirrored repository and the local repository are updated, and as you might expect this fails if you are not connected to your remote repository. To get around this, you create an unmirrored copy of your local repository:
svk cp //epsimulator //local/epsimulator
With SVK these repositories are just like files that can be copied and listed, as long as you precede your cp and ls commands with svk. Now you can checkout, update, and commit from the //local/epsimulator repository and not have to be connected at all to the Internet. When you are connected and want to update the remote repository, the easiest way is to use the svk push command:
svk push
This merges your changes, keeps the change log up to date and synchronizes the local and remote repositories in one easy command. Similarly svk pull can pull any changes to the remote repository to your unmirrored local repository.
There is a lot more you can do with SVK, check out the link above, or these tutorials. Then feel the freedom of version control without being tied to a network.
-DEM
