Links

Ben Laurie blathering


Monotone versus Subversion?

It has come to my attention that various CVS repos with bits of my software in have stopped working. This is because of hardware death and arcane chroot configuration that I can’t be bothered to reproduce.

So, my plan is to move these repos to a new machine and run them under Monotone, because I think Monotone is cool. However, I am prepared to listen to shrieks of protest (with reasoning) that say I should use Subversion. Or, indeed, something else.

BTW, when the Monotone guys presented at CodeCon a couple of years ago, they had this funky graphical depiction of the version history. Anyone know how that’s done?

6 Comments

  1. If the CVS repository is just for your personal use, and it’s not too important to publish it to the public, I would really recommend trying DARCS. DARCS has a completely different model for thinking about version control; David Roundy has invented a well-grounded foundation for some of the icky meaningless bits that have been part of version control for a long time. Read the “theory of patches” appendix to the manual; I had to read it a few times.

    If I’ve understood the rumors, Subversion 1.5 is going to have the long-discussed merging support in it. And that’s due out shortly. (Full disclosure: I’m one of the original designers of Subversion — although I’m no longer an active contributor.)

    I don’t think Monotone has the momentum behind it that, say, Mercurial or GIT does. And as far as I can see, Monotone’s repository structure doesn’t have too many inherent differences from Subversion’s, so I would expect Subversion to acquire Monotone’s features eventually, if they’re valuable.

    Comment by Jim Blandy — 7 Apr 2007 @ 15:18

  2. Bah. If you’re not going to go with Subversion, go with Mercurial.

    See? I didn’t shriek.

    -Fitz

    Comment by Fitz — 8 Apr 2007 @ 4:38

  3. I recommend taking a careful look at git. You can start by reading some of Keith Packard’s thoughts at http://keithp.com/blog/Repository_Formats_Matter.html .

    Comment by Ivan Krstić — 10 Apr 2007 @ 8:30

  4. Mercurial represents history as a DAG. The only merges it tracks are full “from branchpoint up to some point” merges. DARCS lets you pick arbitrary patches out of the development history and revise them. It’s very different.

    If you’re not concerned with collaboration, the DARCS model should be high on your list of things to get your head around, because it changes your understanding of the problem space (for the better).

    Comment by Jim Blandy — 10 Apr 2007 @ 17:14

  5. I didn’t say that right.

    Mercurial only tracks merges whose final results are to have merged all the changes on a branch from its branchpoint up to some given point. What I wrote could be read as saying that you can’t re-merge from a branch, which you can.

    Mercurial’s limitation is that it won’t track you moving individual changes around at will. DARCS does, and gives you a firm foundation for thinking about what that means, even in the presence of renames and hair like that.

    Comment by Jim Blandy — 10 Apr 2007 @ 17:17

  6. It might be worth taking look at “svk” http://svk.bestpractical.com/view/HomePage, I have not used it personally but I know some people who are quite happy with it.

    Comment by Ken — 7 Aug 2007 @ 2:06

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress