Mercurial Workflow for small team

Question

I'm working in a team of 3 developers and we have recently switched from CVS to Mercurial. We are using Mercurial by having local repositories on each of our workstations and pulling/pushing to a development server. I'm not sure this is the best workflow, as it is easy to forget to Push after a Commit, and 3 way merge conflicts can cause a real headache. Is there a better workflow we could use, as I think the complexity of distributed VC is outweighing the benefits at the moment.

Thanks

Answer 1

If you are running into a lot of 3 way merges it might be because you have too much overlap in what you and your team members are working on. Mercurial is pretty good at handling merges itself, so long as you all aren't editing the exact same lines of a file. If possible, you could divide up the work more clearly and avoid some of the headaches of large merges. Also note that this would still be a problem with CVS since it's arguably worse at merging than mercurial.

You also don't need to push after every commit. Your workflow could look something like this:

• Commit part of some feature.
• Commit some more of some feature.
• Commit last part of feature.
• Commit bug fixes for stupid mistakes.
• Push full feature to repo.

To an extent, this looks like Going Dark, but that can be alleviated by making sure that the features in the above example are smallish in scope.

Answer 2

It sounds like you're all making your changes to the same branch. This has the unsatisfying side-effect that you're merging each others' changes on almost every single commit, which would be fine except that manually intervening for conflicts isn't something you want to do every time you push.

Here's the workflow I would suggest. The idea is to use branching more heavily, so you need to merge to the master branch less often.

1. Have every developer develop every feature in a separate branch. This way:

   • you avoid constantly merging changes from other people, and

   • you are free of the pressure to push incomplete work before the next guy, "makes it hard to merge."

2. When a feature is "done" and if the changes would appear to apply cleanly (a judgement call), merge the feature branch directly into the master branch and delete the feature branch.

3. If a feature falls way behind the master branch (many features merged), or if the merge otherwise appears difficult:

   1. merge master into the feature branch.

   2. Find and fix any bugs in contented isolation from other developers.

   3. Assuming the feature is ready to go, merge it into master (notice: now the merge in this direction will be clean by definition). If not, you can just continue developing.

Answer 3

1. Forget all you know about CVS. Mercurial is nothing like it even if some commands feel somewhat similar.

2. Read http://hginit.com/. Follow the examples.

3. Forget all you know about CVS.

4. I mean it. This is the hardest part. Learn to trust your tool.

Answer 4

We are using Mercurial by having local repositories on each of our workstations and pulling/pushing to a development server.

That sounds fine to me. My team is about double the size and it works great.

I'm not sure this is the best workflow, as it is easy to forget to Push after a Commit,

You don't have to push after every commit; you push when you want to push. That's the big idea about DVCS: that Commit and Push are distinct!

and 3 way merge conflicts can cause a real headache.

Are you working on the same lines of code a lot? On my team of 5-6 programmers, pushing/pulling a few times a day, and committing up to a couple dozen times a day, I can't remember the last time I've had to manually resolve merge conflicts. Certainly not in the past month or two.

Is there a better workflow we could use, as I think the complexity of distributed VC is outweighing the benefits at the moment.

Perhaps you should describe your workflow in more detail, because the only complexity over centralized version control that I encounter on a typical workday is maybe one command, and the benefits are huge. Doing "hg blame" just once saves me more time over the centralized version than all the "hg push"es I've had to type all year!

Answer 5

For what it's worth, we're a similar size team working with Mercurial for the first time and we started with the same problem.

We persisted and things are now significantly better. I think most of the problems occurred when the codebase was tiny and people were all trying to work on the same thing. Now that it's a little more established people aren't treading on each others' toes quite so much and the Paris much reduced.

Hope you get it sorted!