Java Posse on SVN and Mercurial

So the guys were discussing version control systems and Joe was talking about SVN. Tor was talking about Mercurial. The only thing they were talking about was stuff that, quite frankly, really doesn’t matter all that much because any revision control system is going to allow check-ins, etc. Obviously thats the point 😉 Joe wonders how dangerous is it to use Mercurial since you’re not checking in to a central repository. You might lose something! Joe…just a note that the same thing is true of SVN if you don’t bother checking in your code 😉

But all this really doesn’t get to what I think is the most important point: what is the merge model like in Mercurial? In SVN when you are merging changes from branch to branch (and in branches I’m including trunk) you have to be really careful with making sure you’re getting the revision numbers right. This is no better than CVS. Sure SVN does most things better than CVS but in this important case it does nothing to make the process better.

I have yet to read about how merging happens in Mercurial. I wonder if you have to track revision numbers as in SVN.

At work we’re looking at Accurev which has a pretty smart model for merging changes. Obviously any merge is going to require some careful checking when you have multiple changes from multiple people to the same area of code but Accurev makes the rest of the process much easier. They use the idea of streams, which are sort of a combination of an SVN branch with workflow attached, and when you merge code you are promoting it to streams higher in the hierarchy. You still have to worry about overlapping code areas, no way around that, but you don’t have to worry about tracking revision numbers.

Now if we could finally get off of CVS…. 😉

5 thoughts on “Java Posse on SVN and Mercurial

  1. re: doesn’t matter. I disagree. I enjoyed the part on Mercurial, as I haven’t read anything on it. Tor (and Dick) convinced me that it is quite a different mindset (i.e. the separation of checking-in and pushing changes). I’m not often intrigued by a version-control system, but they did a good job of doing so.

    Maybe they can follow-up on merging etc.


  2. It isn’t that different of a mindset if you end up having to push your changes to some central repository anyhow for backup purposes.


  3. Just use the svnmerge util ( ‘apt-get install subversion-tools’ for you Ubuntu users ) and you won’t have to manually track what revs you already merged.


  4. Thanks for the pointer Justin! I hadn’t heard of that utility before. I just forwarded it over to some former coworkers who are using SVN.


  5. At work we switched to AccuRev (from CVS) about two years ago. Great decision. Merges are indeed much easier. Also, because of the stream hierarchy and inheritance, we find ourselves having to do much fewer merges, even with parallel development.

    No, I don’t work for AccuRev–just a satisfied customer.


Comments are closed.

%d bloggers like this: