Version control management of large projects

Question

I'm used to version control, in particular I currently use Mercurial. I have some doubts about how to make it work in large teams, where there is a good probability of having more people working on the same file.

Let me make an example with Mercurial (but any decentralized system will be more or less the same). Say we have a central server and three developers Alice, Bob and Carl. The three decide to start working at the same moment and they all pull from the server. By chance it happens that they are working on the same file.

Alice finishes first, and push her changes to the server. Then both Bob and Carl finish, more or less at the same time. Before pushing, they check whether there is something new, and find Alice's commit. So they pull it, and each one merges the changes locally. Then Bob pushes it and Carl pushes its changes.

What happens here is that on the server there are two heads: one by Bob and one by Carl, and both include merges with Alice's work. Whoever now pulls from the server will find a little mess. Of course one can just merge Bob and Carl heads, but that may not be as simple. Bob and Carl may have had different ideas on how to merge with Alice's work.

As soon as more people start working on the project, things can go even worse. So, while in theory I understand how merges are supposed to work, it is not clear to me how to make things manageable in a large project.

How do people manage to resolve conflicts when there are many people working on the same file, possibly having done different merges in different orders?

Answer 1

The way this is done is that every developer must merge changes before they commit a file. I have never used Mercurial so I don't know the commands or the exact process, but in any serious config management tool you will be warned if you try to check in "over the top" of someone else. When you get this warning you should merge the other changes in to your checked out copy, check the build and tests etc and then check in.

This is a very common issue, and merging in this way can be a real PITA, but that's life. The alternative approach of locking all checked out files prevents this issue, but has the serious drawback of blocking everyone else while you work on a file, which in turn leads to people editing uncontrolled versions and then all hell breaks loose...

Answer 2

I'm not sure if Mercurial is different, but git simply won't allow* you to push to a destination that has diverged from your branch (eg. in your case if Bob pushes first, then the server has diverged from Carl's branch). Carl must pull down Bob's changes, commit them, then push.

*well it will, if you use the --force option. But if you have to use that, you should know why.

Answer 3

With mercurial, you can only get multiple heads on the upstream repository if Carl forces his push. What should happen is that after Bob and Carl independently do their merge of Alice's changes, Bob, who pushes first should be Ok, but Carl will get a message telling him that his push would create new remote heads and his push would be cancelled.

The solution of course, is for Carl to pull down Bobs changes, merge them in and then push back that merge too, so that you end up with all three sets of changes.

How often you see this sort of problem will depend on how big your repository is and how often developers work on the same things simultaneously. Also it depends on whether developers have got into the habit of forcing pushes (or set up their tools to do it automatically). If the latter is the case then I would highly recommend against it.

If you see people working on the same code too often, then perhaps you should look at whether your application has an excess of coupling (say a super-singleton that has to be edited whenever anyone changes anything anywhere else in the code) or whether you need to split up your repository into a group of sub-repositories.

Answer 4

Something's wrong with your Mercurial setup (or I don't know how this system is supposed to work). It shouldn't allow the emergence of "two heads". It should be either Alice->Bob->Carl or Alice->Carl->Bob. That's the way it worked in Subversion in both teams I worked for, and we always managed to sort out the conflicts. Continuous merging helps a lot. Trying to merge 2 months' work of multiple developers into a different branch often hurts.

Answer 5

It's really not as bad as you're thinking it would be in practice.

In theory, if two people were working on the same file on the same lines then it's a problem that needs manual intervention.

However, in practice, that situation is very rare. More likely that they may be working on the same file, but in different locations. If the two (or three, or four) developers are working on different sections of the file, the automatic merge is generally smart enough to figure it out.

There are occasions where I've modified a line of code and a coworker has modified the same line so that when I pull the latest from source control, I need to manually merge. But that's rare and usually only happens if I've made a large change that touches a large number of lines anyway (e.g. if I've modified some API that is used by a lot of clients).

Answer 6

Your scenario -- three people -- one file -- is a symptom of poor architecture and poor management.

This is not a tool problem.

Answer 7

I don't know if mercurial supports this, but in a small cohesive team, the centralized workflow may be the best. In this workflow developers have to update/pull from the central server first before they can push a new commit.

In larger or distributed projects, I recommend the gatekeeper workflow:

• The developers do not merge from each other. The gatekeeper merges developer branches into a branch designated as the official branch.
• Developers work on feature branches, and when a feature is done they propose to the gatekeeper for merging.
• The gatekeeper has good overall understanding of the project. If merging a branch results in conflicts, he may need help from the developer to sort them out, but maybe not, as the conflicts should be caused by a merge proposal he recently approved himself.
• The gatekeeper is also in charge of the quality of code and project-wide best practices. He rejects merge proposals that have any problems, the original developer should perform any necessary fixes and resubmit his branch.
• Being a gatekeeper is a full-time activity.
• As the project grows larger, there can be more gatekeepers, forming a hierarchy.