Using git/mercurial on projects with continuous refactoring?

Question

I am trying to understand if I really have any case for using git/mercurial.

The projects I work are java and c# projects, usually with 5-20 people working towards a com

Answer 1

The way your team uses Subversion means that there's a quite a lot of merge effort happening. Almost every time a team member updates to the most recent mainline they are merging their working copy with the latest mainline, even if they don't commit their own changes at this stage. The merging overhead tends towards being a product of commit rate and number of team members, and since commit rate is a function of the number of team members, your source code management overhead is O(N^2).

In the Mercurial/Git model, this merging effort will get shared out among the team. If you routinely pull changesets from everyone then often you'll find that others have already done nearly all the merge work you might have had to do. And, in the cases where a merge has broken something, often people will already have fixed it. Reconciling a pair of branches only has to be done once, and since rate of generating new branches is proportional to number of team members, the source code management overhead is O(N).

I'd expect 20 developers working close to the head on one branch is likely to involve a fair amount of merging work (dealing with conflicts, and dealing with regressions due to independent development), so I'd be surprised if you tried Mercurial/Git and did not find a useful productivity win. Do you think you could manage 100 developers with your current progress? I'd estimate the number of Linux kernel developers at 4000, and yet they get a lot of stuff done and the total source code management overhead must be acceptable.

As long as your source code management system tracks common parentage, merges are often automatic. Each merge has a chance of either being a textual conflict or breaking the build and tests due to interaction between changes; the less merges you have to do the less time you'll have to spend dealing with either kind of problem.

Consequently a really big win is that Mercurial/Git users no longer fear branches. Before BitKeeper (the tool that really introduced this way of working, as far as I know), long lasting branches were time bombs ticking away, occasionally exploding and taking a week to recover from. Now, we can branch without hesitation, with confidence that we will be able to merge later. In a healthy team, others can see your branches in progress and merge them to theirs and commit your efforts later if they think it is worthwhile. In a centralised model, if each developer had 3 or 4 branches active, and I'm correcting in saying it's O(N^2), then you've just increased your source code management overhead by a factor of 3ish^2, i.e. an order of magnitude, which is probably enough to really hurt overall health , wealth and happiness. This is the underlying reason that team members (and managers) typically fear branches in centralised systems and work to minimise them.