Help with mercurial repo problem

I have a repo in a condition I don't understand. 2 weeks ago, I tagged a release to mark a particular point I may have needed to go back to. Later, I decided to branch, and have also been pulling in changes from another repo (the repo that I originally cloned).

The original rev that is of interest is 52:

changeset:   52:5044a88ba2a9
date:        Mon Jan 10 18:09:30 2011 -0500

A few commits later, I branched into "MultiPartition" (I should have done this immediately, but I didn't anticipate needing it).

After some more work, I pull changes from the sister repo (all the changes do not conflict with my work in the branch, so it's safe).

Here's what I see now:

$ hg branches
MultiPartition                75:9fd803c56505
default                       72:3939850a77e2 (inactive)

Where I'm working in MultiPartition, and default is the tip from the sister repo.

If I look at the heads:

$ hg heads
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

changeset:   72:3939850a77e2
parent:      69:997a5b43216d
date:        Tue Jan 18 13:26:48 2011 -0500

changeset:   54:4ad1d36a79aa
date:        Thu Jan 13 19:14:57 2011 -0500

there's rev 54 hanging out there, which I didn't (knowingly) mean to leave behind.

Here's where it gets strange: The changeset 52 isn't in my current MultiPartition tip (though it was actually in the source on my disk, as I expected). I've attached a graphlog of the changesets at the bottom.

If I use the hgcontains extension, I see:

$ hg headscontaining 52
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

which tells me that the contents of rev 52 (which has new files I want in the current branch) should be in the tip of this branch. However, an hg update -C MultiPartition removes the new files from the directory I want them in.

If I use hgtk log and filter by the directory of interest, I see the 52 changeset which adds the files, but no newer changesets have any files removed from this directory.

The only thing that makes me wonder is this: Changeset 71 was the merge from the original repo. In that repo, those new files don't exist. The log for that changset is:

| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500

Here's my core question:

1. If parent 70: has what I expected, but parent 69: didn't, how is that resolved?
2. How can I check for other omissions? Is there a way to see this sort of behavior?
3. I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?

Sorry if this is complex, but I don't know how else to ask the question except for giving a ton of info.

Full graphlog:

o  changeset:   75:9fd803c56505
|  branch:      MultiPartition
|  tag:         tip
|  date:        Tue Jan 18 18:32:38 2011 -0500
|
o    changeset:   74:be7df4e2579c
|\   branch:      MultiPartition
| |  parent:      73:3e7ac80ab37a
| |  parent:      72:3939850a77e2
| |  date:        Tue Jan 18 18:31:24 2011 -0500
| |
| o  changeset:   73:3e7ac80ab37a
| |  branch:      MultiPartition
| |  parent:      71:ba4c67a24185
| |  date:        Tue Jan 18 18:28:51 2011 -0500
| |
o |  changeset:   72:3939850a77e2
| |  parent:      69:997a5b43216d
| |  date:        Tue Jan 18 13:26:48 2011 -0500
| |
| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500
| |
| o  changeset:   70:2dcbf69c325d
| |  branch:      MultiPartition
| |  parent:      66:79272b7e7c0开发者_JS百科1
| |  date:        Mon Jan 17 17:42:04 2011 -0500
| |
o |  changeset:   69:997a5b43216d
| |  date:        Mon Jan 17 12:00:09 2011 -0500
| |
o |  changeset:   68:b39f8a7af0c5
| |  date:        Sun Jan 16 20:23:43 2011 -0500
| |
o |  changeset:   67:63d3b40427e0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 18:07:49 2011 -0500
| |
| o  changeset:   66:79272b7e7c01
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:43:32 2011 -0500
| |
| o  changeset:   65:b33eb978d647
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:39:54 2011 -0500
| |
| o  changeset:   64:1fdafb6d0e84
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:48:09 2011 -0500
| |
| o  changeset:   63:74942ab5113d
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:46:15 2011 -0500
| |
| o  changeset:   62:2cd5a6d9d120
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:55:23 2011 -0500
| |
| o  changeset:   61:acc73e7a35fc
|/|  branch:      MultiPartition
| |  parent:      60:c10e217081f0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 01:53:01 2011 -0500
| |
| o  changeset:   60:c10e217081f0
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:45:16 2011 -0500
| |
| o  changeset:   59:2709b82b3ac0
| |  branch:      MultiPartition
| |  parent:      54:4ad1d36a79aa
| |  date:        Sun Jan 16 01:42:34 2011 -0500
| |
o |  changeset:   58:29029a74e351
| |  date:        Sun Jan 16 01:36:44 2011 -0500
| |
o |  changeset:   57:48840b75e37b
| |  date:        Fri Jan 14 11:04:06 2011 -0500
| |
o |  changeset:   56:dab5f0d40be9
| |  date:        Thu Jan 13 15:51:11 2011 -0500
| |
o |  changeset:   55:214ac45834fd
| |  parent:      51:7d0a1da31199
| |  date:        Wed Jan 12 16:49:00 2011 -0500
| |
| @  changeset:   54:4ad1d36a79aa
| |  date:        Thu Jan 13 19:14:57 2011 -0500
| |
| o  changeset:   53:8f06d69177d6
| |  date:        Thu Jan 13 14:02:42 2011 -0500
| |
| o  changeset:   52:5044a88ba2a9
|    date:        Mon Jan 10 18:09:30 2011 -0500
|
o 

You actually still have two heads on the default branch, and one head on the MultiPartition branch, as hg heads has shown you. Use hg heads -t to see actual heads, regardless of branch. It looks like you use the graphlog extension, so use hg glog -r "branch(default)" to visualize your default branch.

As for your questions:

1. If parent 70: has what I expected, but parent 69: didn't, how is that resolved?

You can hg export -r 52 >52.patch then hg import 52.patch at the tip. This will reapply the changes. One of your merges must have dropped the content.

1. How can I check for other omissions? Is there a way to see this sort of behavior?

Not really. As far as Mercurial is concerned 52 is an ancestor of your tip. If the changes were dropped in a later changeset Mercurial doesn't really know. You can hg diff two different changesets and track down where it got removed (probably in the merge).

1. I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?

default is typically where you want all your development to end up. You can merge the two default heads, then hg ci --closebranch on MultiPartition and merge it into default.

1: If parent 70: has what I expected, but parent 69: didn't, how is that resolved?

I guess the files got removed in either the 61 or 71 merge. You can check this in hgtk with the "diff to second parent" option.

3: I want to not have multiple heads, but I can't seem to "merge" them. Technically, they are already merged (I think). How should I clean this up?

On your default branch are two anonymous heads (54 and 72, where 72 is the tip of default), and they will stay open as long as the MultiPartition branch is not merged back into default. Depite being later merged in the MultiPartition branch, they are still heads of the default branch, because mercurial does not consider a follow-up branch as a new head of a branch. The reason for this treatment is that you typically want the latest revision the a branch when you hg update branch.

You can get rid of the two default heads when you merge MultiPartition back into default. When you are done with MultiPartition you can also close this branch with hg ci --close-branch (technically you cant remove the MultiPartition head, but when it is closed hg heads wont consider it as active head).