Named previously unnamed branch

Question

It seems naming a previously unnamed branch doesn't really work out. It creates a nasty multiple heads problem that I can't find a solution for.

Here is the workflow...

UserA starts working on feature that they expect to be small, so they just start working(off the default branch). The change turns out to be a large project and will need multiple contributors. So UserA issues... hg branch "Feature1" and continues working, committing locally s needed.

UserA then pulls down the changes from the central repo so he can push.

At this point, why does hg heads return 3 heads? It shows 2 for default and 1 for Feature1. The first head for default is the latest change by another user on the branch(irrelevant). The second default head is the commit prior to the hg branch "Feature1" commit.

The central repository has rules enforced so that only 1 head per branch is allowed, so forcing a push isn't an option. The repo doesn't want multiple heads on the default branch.

UserA should be able to push these changes so that other users can see the Feature1 branch and help out. I can't seem to find a way to "correct" this. I don't think I can re-write the branch of the initial commits for the feature, before it was a named branch.

I know the initial changes before the named branch are technically on the default branch, but does that mean they will be heads until that Feature1 branch is merged?

Answer 1

I have found a solution without have to re-clone and merge changes in. I prefer this method mainly for historical purposes as I think it's valuable information on what happened with the feature (aka it started small and then was re-thought to be larger etc..)

In my example, UserA should update to the unwanted head on default and close that branch of default, as it is unwanted. This will leave 2 heads one for default and one for Feature1 as expected.

hg update -r X // X is the rev of the unwanted head.
hg commit --close-branch -m "Moved to Named Branch Feature1, cleaning up initial work"

Then update to the Feature1 branch, push and continue working.

Another workflow is almost the same except the UserA decided to push Feature1 for others to help and default has not been moved forward by anyone else. The local repo only has 2 heads and the user could push, but UserA does NOT want to just push as the tip of default would now be the changeset that really "belongs" to Feature1.

UserA should update to the latest, unwanted changeset of default. Then revert the default back to the revision before UserA starting working.

hg update default
hg revert -r Y // Y is the changeset before UserA started working on the feature
hg commit -m "Reverting changes that now exist in Feature1 branch"

Then update to the Feature1 branch, push and continue working.

Answer 2

The reason you're seeing two heads on the default branch in the local repo is because, after the most recent common ancestor, the changesets in the central repo have nothing in common with the changesets in the local repo.

To solve your problem:

1. Create a new local clone of the central repo at whatever revision you want (it will probably be easier if you use the most recent common ancestor).

   hg clone -r common_ancestor central local2
   

2. Export the changes from the first local repo. Note the colon after first_local_change to get all the changes in that repo.

   cd local1
   hg export -r first_local_change: > ../local1.patch
   

3. Go to the new local repository, create the feature branch to import the changes into, then import them:

   cd ../local2
   hg branch feature
   hg import ../local1.patch
   

   hg import has an option to use the branch information in the patch file, but it's disabled by default.

At this point, you can continue using the new local repo in the original one's place. Also, I would double check to make sure that everything is as it should be in the new repo.

Answer 3

We found this to be a very big problem with our team (doing branch-per-feature) and ultimately stopped the hgweb.cgi script working (HTTP 414 Request too Long).

Answer 4

from hg help heads: hg heads with no args will show branch heads, which by definition are changesets that have no children on the same branch. hg heads --topo should give you result you need in this case.

Answer 5

Don't go via the central repository. Just have your developers pull from each other.