水星：从未知的分歧“分支”合并

Question

I'm trying to do some work on a project called NS-3, but my problem isn't project specific so I thought I'd ask here as well as the relevant mailing list.

Basically, a copy of the then current project code was made, and a fresh repo made of that code. Work was done on both the 'forked' version and the trunk.

So cloned the forked source, cd in, and hg pull <latest-dev> , hg merge , and while it wasn't a perfect merge, the changes that were unmergable were all related to one library change, so easily fixed (in theory). Naturally this optimistic attempt failed to build.

Now I'm not entirely sure where to go from here, I'm new to DCVS so please; ideas directed towards a 5 year old!

How can I find out which changeset of the forked version was last merged against the dev-trunk since they're separate but related repos?

Answer 1

The Case Where You Started With a Copy Not a Clone:

If this is what happened:

1. Project Exists
2. Copy (not clone) of project is made
3. hg init is run in each separate copy, creating two unrelated repositories
4. work is done in both copies

Then to merge them you want to do this in the newest of the two unrelated repos:

1. hg update 0 , which jumps the repository back to its earliest point -- the point where it last looked identical to the other
2. copy in the contents of the working directory from the other repository
3. hg commit , which creates a new head
4. hg merge , which merges the two heads and also provides a base revision, which helps the merge process.

The key is getting a base revision involved if possible. What DVCS systems bring to the table that CVS and SVN don't is that every merge is a 3-way merge between two heads and the most recent common ancestor. Faking that common ancestor by creating the new head off the last point the two repos looked the same (revision 0 in the copy) simulates a base revision.

Answer 2

The Case Where You Started With a Clone Not a Copy

This is the classic DVCS case and there shouldn't be much you need to do. Just go into one of the clones, hg pull from the other and fire off the hg merge . If the merge requires input you'll use hg resolve to provide it, and when you're done hg commit .

If at this point your code isn't building/running then you need to just start debugging. Use hg blame to see what was being done near the lines that won't compile and try to suss out what was being done and how to work on it.

The merge process is much easier the more frequently you do it. Pull in up-stream changes daily, not monthly.

You can turn on the GraphLog extension and use the hg log -G command to see the point at which the two lines of development diverged, but in the end merging is development, and you just need to approach a non-building merge like you would any other software defect.