With Mercurial, common practice to create 2 or 3 clones of the same project as standby?

Question

I heard that if we are working on a feature and then we need to fix something quickly, we can make a temporary clone and then fix the bug, and push to the central repo.

First of all, is the temporary repo cloned from the central repo or from our local repo?

Also, is it good to clone 2, or 3 repos from the central repo to our hard drives, so if we are working on a feature using local repo 1, and need to make a quick bug fix, then we can go to local repo 2, do an hg pull, hg up, and make the bug fix, and hg push and be done with the bug fix without affecting local repo 1?

So we will keep local repo 1, 2, 3 always there, so that we have them as standby, without needing to create a new temporary clone each time, which can be time consuming.

Update: I think one suggested practice from the answers is: clone from Central repo to local repo only once (and call this local repo as "master repo"), and then clone from this local repo "on demand", fix the urgent bug in the tmp repo, and push directly from tmp repo back to the Central remote repo? However, isn't it said that during development, we should commit often (even before the feature is totally finished and bug free), so if we clone from local repo to a tmp repo, won't the clone include those committed files as well? And what if the urgent fix require modifying the files that are in the local repo that are in "intermediate" state (in the middle of development)?

Answer 1

My practice is to have a 'master' clone of the central repository, and then for each feature or bug fix I am working on, I clone the 'master'. As I finish a feature, I push it back to the 'master', then when I am confident I push to the central reo.

Here are some Mercurial Best Practices

Answer 2

The answer really depends on how expensive is it to push changeset to the master repo.

If your master repo has very few (or none) quality gates, pushing your changesets is cheap both on you and the team as a whole. In this case you can opt-in for cloning the master repo on the fly, doing quick fix and pushing it back up, so it goes as quickly as possible to the rest of the team and to your automated builds (assuming you have CI set).

If your master repo has complex set of quality gates (pre-push buddy test/verification, automated integration regression, daily build and automation and so on), pushing any change to the master repo is quite expensive on you and your team. In this case, you should consider cloning your main local repo, making the fix, and pushing it back to merge with your other changes, in order to batch as much of your work before pushing back to the master repo.

Answer 3

I would go crazy trying to keep track of the state of multiple local clones. Cloning on demand is the way to go. If cloning is really slow, you have two choices:

• If the slowness is owing to the network connection, you can set up a local clone that automatically mirrors the remote repo, and that is eagerly updated whenever the remote repo gets a changeset.

• If the slowness is inherent to Mercurial, perhaps you ought to revisit the question of whether Mercurial is providing what you need in a revision-control system.

Answer 4

Definitely clone from the master repo only once. Then clone on-demand locally as you start new features. Push from those clones of your clone directly back into the central repo. Essentially then my work flow looks like a circle

Remote-Master --(clone/pull)--> local-never-modified-clone --(clone/pull)--> local-modified-clones --(push)--> Remote-Master

The advantage here is that cloning your own local clone should be near instantaneous. On modern file systems mercurial uses hard links for the repository files and breaks them only on changes, so a second clone of a repo (from a local source) takes up only the space of the working files.

When creating my local-never-modified-clone from the remote-master I use clone -U to avoid creating a working copy at all so I'm not tempted to work in there. Creating a new local clone for working from that takes just a second or two, so there is no need to keep a few lying around so long as you have the never-modified local clone from which to clone.

Answer 5

And what if the urgent fix require modifying the files that are in the local repo that are in "intermediate" state (in the middle of development)?

Then, once you clone the local repo, checkout a past commit before you started working on the main branch that caused the "intermediate" state, fix the bug, and push back to remote master. It'll look something like this:

@ (under development)
|
| @ (fixed a bug)
|/
|
o (last good commit)
|

Alternatively, you can clone your local repo up until "last good commit", excluding the ones that are under development (using hg clone -r <rev>).