Many years ago, I used CVS for my personal projects. After that, I used Perforce. The free perforce license for small guys was a good thing, but I didn’t find perforce to be the perfect solution. It had its issues with branching, web support, and other little nits. When subversion was mature, I started using that. After moving to subversion, I thought I had a great solution that had the good features from Perforce (like the atomic commit) with an environment similar to CVS. Oh yeah, I also hated the perfoce ‘edit’ procedure. I should never have to worry about my workspace becoming inconsistent with my scm. CVS and Subversion are very good about that.
So back to the story. I’m using subversion at work and I had to do some branching and I was about to do a merge. I had never done one so I read up about it.
Wow. What a let down. They really didn’t have a solution for that. Essentially, you, the programmer, have to keep track of the last items you previously merged! You would think in the era of gigahertz cpus and gigabytes of storage that saving this information wouldn’t be a hard problem.
This prompted me to research the SCM space again. It’s actually an interesting space. Recently (the last 5-6 years), there have been a lot of alternative and interesting SCM systems developed and released. One of the ones that a bunch of friends use is darcs. darcs is written in Haskell and it allows the developer to treat every workspace as a repository. Steve thinks it works well for him, but acknowledges issues… especially performance. I was considering reading more about it and possibly switching over when I stumbled upon a different solution.
svk is a tool written on top of the subversion storage system. It is written in Perl and it delivers distributed/disconnected development (like darcs and a few others), and a smarter merge (like GNU arch). It even does this without having to get rid of your existing subversion repository, which is very nice! There are already a lot of tools that work with subversion so keeping that investment makes the decision easy.
Did I mention that the merge is smart! 🙂 It’s called smerge and it is much easier to use than the subversion merge.
So after doing a lot of research, I started noticing that various tech bloggers had good things to say about svk. There are also some decent tutorials on the net as well.
So…. I decided to try it out. They have Windows binaries that install easy on the main site. I followed the example usage documents and tried it out. Here is what I learned:
The software is quality work. All commands and operations had help and functioned correctly.
ALWAYS use a local branch for smerge, push, pull operations – and always use ‘-C’ to see what it would do. I made a mistake and pushed a merge the wrong way (from dev to release). I was also using a non-local branch (ie. a mirror) for the operation and I was online. The net-net was that I pushed the wrong code and it got propagated live to the main subversion repo. I had to spend a lot of time fixing this. NOTE, this was really a user-error, not a flaw in svk design. They tell you to use a local branch because everything is geared towards using local branches. Also, doing things with the trunk tend to not work the way you would expect. svk assumes you are on a branch since the branch has a known spot where it forked from the tree, whereas the ‘trunk’ does not.
After I used it for a day, I find that I like the way it works better than subversion. The merges worked and I was more productive with the mirrors setup. I’m also pulling in more mirrors since I have more than one repo that I’m using.
OVERALL, I think this is going to be a great new tool for the toolbox and I highly recommend it.
I happen to be a bit of a SCM geek (we are using Arch over at GUBA, and I’ve never met anyone else that actually knows about it.) Right now though, I’m a gigantic Bazaar fan, which emerged from Arch after Tom Lord’s abandoned it again. I use it for all my personal projects now, it’s just amazingly easy to set up and use, and since it’s written in python with a plug-in system, I think will allow it to quickly emerge to be the head of the pack. Though it’s features are really built for DRCS, it also really lends itself to solo user usage incredibly well. For instance, this is all you have to do to start versioning your code:
% bzr init % bzr add % bzr commit -m ‘First commit’
No setup of servers, repositories or apache. I looked into SVK, without using it, because I felt just like CVS was a hack on RCS, and inherited it’s flaws, SVK won’t ever be a true DRCS, since it has to rely on SVN (which last time I checked, you still can’t do a true rename!)