22

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?

Community
  • 1
Matt
  • 221
  • 1
  • 4
  • It seems almost as if you're already using SVN as a DVCS (with respect to branching, anyway). I'm sure you can do nearly everything Mercurial can do with SVN (and vice versa); the question is then, which one is easier to use and more convenient for your particular development scenario? I think you'll need to try out Mercurial for a little bit to see for yourself whether it's worth it or not – Cameron Jun 26 '11 at 20:53
  • I'm a fan of Mercurial and it clearly offers a superset of the features of SVN, but that being said those extra features are only really useful for a small minority of projects. You probably don't need it, it won't change your lives, but you'd be getting more features and losing nothing, so why not? – jiggy Jun 26 '11 at 22:51
  • Have you checked out [Hg Init](http://hginit.com/)? It's a Mercurial tutorial written by Joel Spolsky. It starts with a chapter for Subversion users, but otherwise expects you know nothing about DVCS. – Barry Brown Jun 27 '11 at 19:43

4 Answers4

11

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 2
    +1! Also, if you give mercurial a fair and thorough try, I'm certain you won't want to go back. – Pete Jun 26 '11 at 18:18
  • 1
    "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" ... "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." We have all of that now with subversion. – Matt Jun 26 '11 at 19:42
  • @Matt, then you're lucky as your business is more the exception than the rule. Most companies have very strict rules about creating branches on the limited resource of the central server, so people don't even think about creating them for temporary reasons. – Karl Bielefeldt Jun 26 '11 at 21:21
  • 3
    I think that this answer is missing the fact that the original poster is already coercing SVN to work in a way which is much closer to a DVCS workflow than most users of SVN would consider viable. In essence they *already have the DVCS mindset* so no *fundamental shift in thinking* is required. – Mark Booth Jun 27 '11 at 17:09
  • Good point @Mark. On such a small team, a lot of the normal conventions for larger teams go out the window. I still think it's worth it for speed reasons. – Karl Bielefeldt Jun 27 '11 at 19:15
1

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.

Mark Booth
  • 14,214
  • 3
  • 40
  • 79
  • 1
    SVN doesn't pop a conflict in the case you mention either. It only pops up when you both change the same lines. Merging is generally a problem more with file renames/moves or add/delete in svn because it doesn't handle merging directory changes well. SVN merge gives you more options than those 2, typically I use the "use theirs then mine" as you generally want to keep both sets of changes, not delete them both! – gbjbaanb Jun 27 '11 at 16:56
  • @gbjbaanb - That's not what I've found, which is why I qualified my experience of SVN with `at least the version I've used`. My understanding is that the latest version of svn *does* understand about common ancestors, but I have no experience of that and I suspect there are many servers out there running older versions of svn which have the same problems. – Mark Booth Jun 27 '11 at 17:00
  • Incidentally, I love the fact that with `hg` (and almost certainly `git`, but I haven't tried it) you can take a file with three classes, split it into three files with a class each, then later merge in changes between a branch with the 'combined' file and a branch with separate files such that changes to the individual classes get applied to the correct files. Pure magic. *8') – Mark Booth Jun 27 '11 at 17:07
  • 1
    gbjbaanb is correct; SVN would not have a conflict in the scenario you describe. It is pretty easy to demonstrate this to yourself. – Jeremy Jun 27 '11 at 20:06
  • @Jeremy @gbjaanb - Does the edited section work better for you? I'm not going to argue with you about how `svn` merges should work, I have my own experience with it the `svn` command line and SVNKit under Eclipse where simply pulling in updates can result in 'conflicts' which have to be resolved manually with cut and paste (I can't easily say 'I want both of these changes, in this order). – Mark Booth Jun 28 '11 at 09:09
  • No...you are still saying you have only two options for the text to use as if that applies for the entire file, when it actually applies on a line by line basis. – Jeremy Jun 28 '11 at 12:55
  • @Jeremy - Does my new edit make what I'm trying to say clearer? – Mark Booth Jun 28 '11 at 17:41
  • SVN does a merge by creating a patch (effectively) from the old to the new code, and then applying it to the destination. If you have an update to the destination too, then that's just 2 patches that need to be applied. The DVCSs don't do this, they merge the entire file contents. This is also why you'd have problems merging code split off to new files - it doesn't track add/delete/move of files very well. Still, with conflicts, you can tell it to 'force apply' these 'patches' so you keep the changes from one, and then from the other. – gbjbaanb Jun 29 '11 at 15:48
1

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 :-).

dfjacobs
  • 111
  • 3
  • Do we want to take the time to change? No, especially not when we only switched to svn in the last 2 years. Thanks for your comments. – Matt Jun 27 '11 at 23:54
0

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.

SK-logic
  • 8,497
  • 4
  • 25
  • 37