Recommended guidelines for Mercurial setups

Question

I've just recently installed mercurial, and have been playing around it with. Overall, it seems like a great way to do version control. However, the distributed nature of its architecture makes it so flexible, I'm not really sure what the ideal configuration/topology is.

I'm well aware that asking something like "what is the ideal Mercurial topology" will never get a meaningful answer without more specific details ranging from business requirements, number of developers, security concerns, nature of the project, etc.

However, are there any general guidelines or "best-practices" when it comes to setting up a Mercurial system? In particular, I'm interested in hearing if most companies/projects setup a centralized, "canonical" repository. Mercurial doesn't require that you do this, and you could essentially say anything is the "canonical" repository. (Perhaps you could consider the lead developer's working repository the "canonical" one.)

But is it generally a good idea to setup a dedicated "source control" server which simply hosts the canonical repository, so every developer can clone it and work locally? Or is this unnecessary?

Answer 1

The notion of one "central repository" is the usual setting for a team to work together, as Hginit.com illustrates:

But with a DVCS, you need to remember that:

• there isn't necessary only one central repo, you can setup many replicated version of that central reop for different purposes (testing, pre-deployment, ...)
• a unique central repo for everything will never work: you cannot put everything in a DVCS repo, because it will get too heavy to clone around, or it will contain unrelated set of files that get all referenced under the same tag, which don't always make sense.
  You need to rethink the organization of the set of files you want to manage, and keep them in separate repositories.

Answer 2

The wonderful thing about mercurial is there is no required way of doing things, you can make your workflow follow what's convenient for you.

I think a minimum system is probably a remote repository and a developer repository cloned from it. But how many deployments you have, how many developers you have, what the lines of responsibilies are and how best you can factor these into your workflow might be very different for different teams and/or projects, even within the same department, let alone company.

For instance, using the example from the hginit that VonC posted, if Bob found a bug in code that Rose maintained, he could hgserve his own repo, she could pull in his changes, update to his tip, track down the problem, and push her fix directly back into Bobs repo (without it going through the central server) before updating back to her own work branch. When Bob was happy with their work (he's confirmed that his integration tests run Ok) he could push it up to the central repository, where Joel could see that it was complete.

If I understand it correctly, this is actually easier than with git where Bob and Rose would be expected to collaborate through a shared bare repository. I suspect that Bob would have to clone his own repository, let Rose pull from and push back to that repository, and he would then have to pull her changes in, rather just updating to a newer changeset in his own repo.

Later, Joel decides that this ad hoc sharing isn't appropriate and that all sharing should go through the central repository, but he doesn't want the head of the central repository to ever be in a state where it doesn't pass integration tests.

To solve this, Bob could set up a staging repository. Any repository pushed to the staging area would have the integration tests run on it by the build/continuous integration server and if the tests succeed, the changeset is pushed up to the central repository. If not, the changeset would be held back until tests do succeed. If only the integration server is allowed to push to the central repository, Joel gets what he wants - Bob and Rose can collaborate by pushing and pulling through the staging area, but the central repository would always have a clean, tested build.

So, in summary, The world is your oyster really.

The scenarios above are just two of a wide variety of different problems you might want to solve through your workflow. The best thing to do is to ask if you have a specific workflow problem that you want to solve, then people can offer suggestions. Until then, it's probably worthwhile just keeping it simple.

Answer 3

> what is the ideal Mercurial topology ?

I like the topology and workflow described in a-successful-git-branching-model.

Note the text is about git and not about hg/mercurial but the idea behind is the same.

Answer 4

What matters is the process by which you get code from different developers integrated into a machine so it can be compiled, tested, and packaged as a deployable release.

I've used the an agile "integrate and unit-test before sharing" before. You need a central, shared repository to do this, and the truth is that process works only if everyone knows what they are doing.

I proposed that scheme to a current client, and they opted for an "integrate by selectively pulling/patching" strategy. In that there's a central, integration repository, but it is only accessible by designated integrators.

Another possibility is to combine the above strategies in a two stage process.

In short, if you define the integration process that works for your team, the required repository topology should become evident.

At any rate, do have developers commit frequently to their local repositories, as that can save you from a lot of grief when the builds in shared/central repositories get broken.