We're Subversion Geeks and we want to know the benefits of Mercurial [closed]

Question

Having read I'm a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS.

I have a related follow up question. I read that question and read the recommended links and videos and I see the benefits but I don't see the overall mindshift people are talking about.

Our team is of 8-10 developers that work on one large code base consisting of 60 projects. We use Subversion and have a main trunk. When a developer starts a new Fogbugz case they create a svn branch, do the work on the branch and when they're done they merge back to the trunk. Occasionally they may stay on the branch for an extended time and merge the trunk to the branch to pick up the changes.

When I watched Linus talk about people creating a branch and never doing it again, that's not us at all. We create probably 50-100 branches a week without issue. The biggest challenge is the merging but we've gotten pretty good at that as well. I tend to merge by fogbugz case & checkin rather than the entire root of the branch.

We never work remotely and we never make branches off of branches. If you're the only one working in that section of the code base then the merge to the trunk goes smoothly. If someone else had modified the same section of code then the merge can get messy and you might need to do some surgery. Conflicts are conflicts, I don't see how any system could get it right most of the time unless if was smart enough to understand the code.

After creating a branch the following checkout of 60k+ files takes some time but that would be an issue with any source control system we'd use.

Is there some benefit of any DVCS that we're not seeing that would be of great help to us?

Answer 1

To rephrase your question, "If we plan on only using DVCS in a centralized manner, what benefits does it have?" When you ask it that way, it doesn't. One branch per task is extremely common in VCS. If you think about it, having a local working copy of the source code on a developer's machine that changes independently of the trunk for a day is a branch, even though no one calls it that. The only difference between that and your workflow is you are giving those branches a permanent name on the central server as well. That's not the kind of branching that Linus and others are talking about.

To understand DVCS requires a fundamental shift in thinking. You have to ask yourself what you would do with as many branches as you want that are shared with whomever you want, and only them. That includes branches that are only seen by yourself.

The possibilities are endless. For just one example, how about two people working on opposite sides of an interface? They need to share code with each other regularly, but it's not stable enough to share with everyone yet. They can create a branch to share among themselves, then merge it back into the central repository when it's ready.

The ability to do intermediate local commits is worth it all on its own. That's something you just have to experience for yourself.

The speed gained from having your repo local is also worth it all on it's own. Yes, the initial clone will be unavoidably slow in any VCS for a 60k file repo, but once you have that, checking out a new branch is orders of magnitude faster with a DVCS.

Answer 2

For your particular case, there is no benefit in switching to a DVCS. You're happy with your existing system, it does everything you need, so why switch? SVN is still an active Open Source project, and has better, more mature integrations with all of the major IDEs and development tools than either hg or git. Given the size of your team and the number of projects, do you really want to take the time to convert to a new tool when the existing one is working just fine?

If you have developers that just can't function without a DVCS, point them to the svn gateways for hg or git. Make it very clear to them that their checkins to the svn repository have to conform to whatever procedures and processes the rest of the team use. Another advantage of this approach is that the true DVCS zealots that are already using the gateways without telling you can now come out of the closet :-).

Answer 3

It seems to me that you are already using a workflow which is very similar to the sort of work flow many people adopt after they start using a DVCS.

From your point of view, a DVCS will have the following significant advantages over SVN:

• Once you've cloned your repo(s) many operations can be performed locally.
  • Looking at the repository log doesn't need to touch the svn server, so can be incredibly fast.
  • Similarly, switching branches doesn't require access to the server, nor do local clones.
• Because branches are just divergent paths through the history, your repository isn't cluttered with every branch anyone has every created (we only really have release branches in SVN, but the branches directory still has many subdirectories which are no longer relevant).
  • In git, once a branch has been merged back in and the ref deleted, you might never know it was even there.
  • In Mercurial you have the choice of either naming a branch (in which case it's encoded into each changeset in perpetuity) or just creating an unnamed (topological) branch, which will quietly merge into the history when it is merged back into default (trunk)
• In SVN, branches of branches are far too obscure to be useful. In git and hg they are just par for the course.
• DVCS' understand that software development is a DAG, i.e. when you merge, you end up with a changeset with multiple parents. SVN (at least the version I've used) doesn't really understand this.

On that last point, you say

Conflicts are conflicts, I don't see how any system could get it right most of the time unless it was smart enough to understand the code.

In switching from using hg exclusively to using svn alone and then gitsvn it has been my experience that merges are much simpler and trouble free with hg and gitsvn than they are with svn. Merges with svn (at least the version we use) produce significantly more conflicts which need to be resolved manually.

One of the reasons merges are more difficult in SVN is that it only gives you two options for each line that differs,

• the text from the branch that you are merging in
• the text from the branch that you are merging into

while merges from a DVCS will typically give you a third option, which is

• the text from the common ancestor of both branches that you are merging

Don't underestimate just how beneficial this is, it provides you with much better context for the changes than a simple two way diff could.

All in all, I would suggest that you give it a try. With tools like gitsvn and hgsubversion, you can even try them out with your current SVN repos.

^{Note, creating the clone in the first place is a royal PItA, but once you've done that, you get most of the power of of a DVCS with your existing CVCS.}

Answer 4

There is one important change I've noticed after such a transition: I switch branches much more often, and I commit more often than I could ever afford with Subversion. For example, there is a number of tiny functionality branches, organised in a sequence, and I can spend months adding bits to each of them, easily rebasing them all sequentially to an ever-changing trunk. Rearranging the order in which functionality branches are merged is trivial.

But, in fact, I have not actually moved away from Subversion. I'm just using git as my local svn client.