Not satisfied with your current Version Control System - discussing switching VCS

At work we are getting increasingly annoyed by the rather old Visual Source Safe we are using. We are going for AccuRev as a replacement. There is an interesting comparison with Subversion. Their Subversion notes might be true, in the sense taht you do need some scripting skills to take full advantage of Subveresion branching and merging. Perhaps this is what you get for the license fee. AccuRev server does on Windows, Mac and Linux, not sure about BSD flavors. It does not come for free:

AccuRev is typically licensed using a named user license model. The
list prices for AccuRev end-user licenses range from $750 to $1,995, depending
on specific products licensed, number of users, and required integrations with
3rd party products (e.g., AccuBridge)

If you want a good reading of version control system discussion and thoughts, I recommend reading the FreeBSD Wiki on the VCS subject. It is very well written, and touches many aspects of version control (also some you probably didnt think about). Of course it is written with reference to the FreeBSD project needs, but if you are a familiar with FreeBSD branches and ports, and working with vendor code for your self, you might get a lot of knowlegde and ideas from reading it. I found it very interesting :-)

In short it is a discussion of open source version control system alternatives, with description of desired and required features, in order to justify the cost of FreeBSD project switching away from CVS. Is similar to our own thoughts on changing version control system here at work.

Most is written by Peter Wemm, who is vouching for Subversion. Here is a snip from Peter's view on why FreeBSD need a new VCS and why Subversion should be the prime target. Should convince you to start reading :-)

Why does my opinion matter? I've been doing this for a while. For the last 13 years, I've been the 'The buck stops here' guy for our repository. I've seen it all. I wrote the rules about what we can and can't do in the repository. I did the hacks to the cvs system to prolong its use for us. I came up with or implemented most of the hair-brained ideas that we live with on a daily basis.

Here are my snips from my reading through all the sections:

Automated or mechanically assisted merging. FreeBSD's development model requires that (unless it's an exceptional circumstance) changes first go in to the HEAD. If they are suitable candidates to go in to stable then they should be merged to the relevant stable branch.
In addition, new features may first be developed on a separate branch, before being merged in to the HEAD.
The VCS should support easy merging of changes from HEAD (or its equivalent) to the stable branches, and from feature branches to HEAD. Merges should also be able to go both ways, and be easily repeatable (e.g., a long lived feature branch may merge changes from HEAD on to the branch several times, and may merge changes from the branch back to HEAD several times)

Branch, Easy & cheap branches (and history-aware merging) and tags to enable parallel lines of development (that is essential for projects like SMPng which have a very big impact on many source files)

SVN Repo Layout: A proposed repository layout if FreeBSD moves to Subversion. This includes a good suggestion of handling Vendor code.

SVN Merging: A walkthrough of merging changes with Subversion and svnmerge.py. This walkthrough of branching and merging is very educational :-)

ACL, Access control: the ability to constrain developers to operating in specific areas of the tree, implement branch-based policy restrictions, as well as to enforce policy such as tagging of commits for developers working outside their normal areas. Implementing these via hooks would not be a regression from what we currently do in CVS.

Offline, Ability to work offline -- like on a plane -- without requiring too much work: not only being able to list differences but also to commit

SVK which brings history-aware merging and distributed features to SVN

There are some really interesting (biased of cource) quotes when it comes to comparing Git and Subversion conversion going from CVS, which are right on, and makes you think:

For us to switch to svn would be an evolutionary step. We could use it
as a better cvs, with the sharp edges fixed. hg and git require more of a
revolution in the way we go about things.

git/hg make it very easy to take stuff offline....Encouraging the
taking of stuff further offline is going in the wrong direction for *us*. If
anything, we need to make it easier for people to get stuff to us and in the
tree in some form.

Linus wrote git to suit his needs for linux. He has one thing going for us that we don't. There is a large cult of personality surrounding Linus. There is intense pressure to "validate" your work by getting it approved (directly or by proxy) by Linus. On the other hand, we already have problems extracting work from people. We can't assume that we'll get the same inward flow that Linus gets.

From http://lwn.net/Articles/246381/ - there are some choice quotes. The topic is the problems the KDE folks had making git work for them.

We're not Linux. A good number of our best supporters stick with us because we're a coherent tree and not like linux' chaos.

Why do you seem to be pushing subversion?It's because I am. I think the whole hg/git thing is a distraction.

• it works the same way we've become accustomed to cvs working. Except without most of the silly problems/restrictions.
• there are a huge bunch of tools out there to talk to svn. Things like svnsync (cvsup for svn repository replication) are out there.
• We can use live changeset based exporting to export the tree to cvs to maintain HEAD and RELENG_* branches. Our end users will be able to keep doing exactly what they've always been doing for getting their "fix" of freebsd.
• svk, as an optional add-on, gets you the ability to have a private playground, in spite of my encouragement to work on the public servers.

Notes on Git Conversion: Why git is interesting to FreeBSD, is also very educating. From the little bit of Git reading that I have done, it seems to me that Git gives abilities to hide development cycles, not something I would appreciate in the projects I participate in. Some Git quotes:

git is distributed

Now, you can commit as you develop, then test, then push. If
you find things in your testing that are wrong, you can commit fixes before
pushing, or even go back and edit your local history to erase your mistakes,
making you look even more ninja than you really are.

You can also push your
changes up to a personal repository for others to access. They can merge it to a
personal tree of their own, do repeated merges all sorts of directions, and have
it just Do The Right Thing.

I am a fan of Subversion, and it works on many platforms. So far Subversion has fitted all my needs for version control, automation, documentation, management etc!

After reading the above articles I am even more convinced Subversion will continue to meet my needs, so I am not changing :-) SVK is something for me to try though. And AccuRev might prove useful for the enterprise, we will see.