3

Assume for a minute that the branch/merge support in SVN is as good as in Mercurial.

Consider on the one hand a SVN system where people always work in their own private branches, and then when they are at a suitable point, merge their private branch into the "main" (or whatever their "parent" branch happens to be). Periodically they can merge the other way to get their private branch up to date.

Then on the other hand consider the Mercurial set up of having a central repository and each person pulling and pushing to/from their own repository to which they commit as and when they choose.

So the private branch in SVN corresponds to the local repository in Mercurial and the pull/push in HG corresponds to merging to and from the private branch in SVN.

Does this not allow SVN to essentially mirror the Mercurial set up in this instance? What other advantages does Mercurial have in the scenario?

Note that my opening sentence -- "assume for a moment" -- at least in the version of SVN we have, is where the SVN model falls down for us. The amount of merging that it would involve, and particularly the merging back and forward between the main branch and private branch would be conflict hell. If SVN were as good at tracking branches and merges as Mercurial, would that solve the issue in SVN? Is the latest SVN server code that supports tracking branch tracking up to that kind of use?

Thanks.

Tom Quarendon
  • 5,625
  • 5
  • 23
  • 30
  • 1
    I would also add speed as most of the operations are local. – Keerthi Ramalingam Jan 04 '11 at 11:09
  • Certainly only the push/pull would be remote, whereas in the SVN scenario all commits, and then the merge/update would also be remote. That's a good point. It allows you to stay disconnected longer. SO rather than having to be connected simply to commit a change, you only have to be connected to do the push/pull. – Tom Quarendon Jan 04 '11 at 11:33
  • don't forget that's a 2-edged sword: in a DVCS you can commit disconnected, but your changes are still held locally and not saved in a remote area, so if you laptop gets stolen, you've lost all your work. So you often have to connect to commit, for safety, anyway. – gbjbaanb Jan 04 '11 at 14:43
  • However, there is nothing preventing you from using private branches in Mercurial, so all commits on the branches can still be pushed to the remote repository. Distributed version control doesn't prevent you from designating a particular repository as special (it just doesn't require it). However, other concerns, like data backups, often mean it is still useful to have a central repository. – Stephen C. Steel Jan 04 '11 at 16:28

2 Answers2

3

No, Subversion is still not able to merge as robustly as Mercurial. I give an explicit example of how Subversion fails to merge two branches this answer. There is nothing that prevents a centralized system from being good at merging, it is just that branches are used so much in a decentralized system that it is forced to be good at merging.

Apart from the merge support, the bigger advantage of Mercurial over Subversion is the flexibility of decentralized version control:

  • You can make many small commits and then do hg rebase --collapse to combine them into a bigger and better commit before you push them to the world.

  • You can use the MQ extension or the rebase extension to refine changesets before you publish them.

  • You can commit safely, and then change your mind and throw things away with hg strip or the more safe hg clone -r.

This lets you experiment more freely and the end result is that Mercurial becomes a supportive safety net instead of a hindrance. It's deeply ironic that tools like Subversion end up being something that people don't use -- they don't commit their changes for days because they are afraid of breaking the build, and they wont use branches because they've been burned by them in the past.

The above were just local flexibility -- Mercurial also lets you orchestrate nice flows of changesets between repositories: you can have a repository where a gate keeper does QA and only lets changesets through after testing them. That kind of flexibility is built into the decentralized model.

Community
  • 1
  • 1
Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
2

Another issue to be concerned is the developers would feel reluctant to do a submit of half-baked code in subversion even if it is a private branch as their incompleteness would be visible to their peers. The peer pressure to submit great working code is very high in a centralized version control system. This leads to infrequent commits which compounds merge bigger merge issues.

In a DVCS developers can do anything with their code and still do a submit as no one else will come to know about the changes until the changes are pushed. They have the privileged of experimenting thereby increasing productivity and efficiency of code because anything they do can be reverted.

Keerthi Ramalingam
  • 610
  • 4
  • 10
  • Though I use private branches myself, and have to issue checking in half backed code if it's just a point I want to preserve, I'm the only one in our group who ever uses private branches in SVN I think, so yes, I can see the benefit of this. – Tom Quarendon Jan 04 '11 at 14:59