Home

On designing a version control system

We’re currently evaluating candidates for replacing CVS as a lot of shops are doing. That’s not an easy job - Subversion has horrible merging support, Arch often makes simple things hard (so needs padding in shell scripts, probably), and I’m not sure that I want Darcs because I’m not sure that I can patch a system written in Haskell if the need arises.

Anyway, this is not about our software selection process. We’ll just pick one and stick with it, probably :-) . What triggered this entry is this post by Arch author Tom Lord. He tries to diagnose what’s wrong with Subversion, and even where his ideas are not completely hitting the nail (rebuttal by Gred Hudson here), he points out several issues that are applicable to other contexts. That makes it worthwhile reading in any case.

Personally, I think SVN missed the bar, especially where merging and multiple-repository development are concerned. But then, I’ve been spoiled over the years by the likes of Cincom VisualWorks’ StORE and Squeak’s Monticello, which exposed me to the advantages of multiple-repository development and made me assume that merging “the right thing” is just there in any decent VCS.


Stumble it!  Post to del.icio.us 

3 Responses to “On designing a version control system”

  1. Brian Zhou Says:

    Although may not as feature rich as darcs, mercurial is written in Python and C, probably worth a look.

  2. Faried Nawaz Says:

    Darcs runs wherever ghc (the haskell compiler) runs. Notably, this means it won’t work on amd64 (Athlon64 or Opterons, or Intel’s processors running in EM64T mode). This may nor may not be a problem for you.

    Have you looked at svk?

  3. cdegroot Says:

    I have looked at svk. In fact, I think that svn+svnmerge+svk is not an entirely unreasonable option.

Leave a Reply

(note: comments may be moderated so don't always appear right away)


Copyright (C)2000-2005 Cees de Groot -- All rights reserved.