Impact of splicing a merge via hg convert.

[Matt Mackall]

On Thu, 2011-10-06 at 14:45 -0400, Tom Udale wrote:
> Hi Matt,
> 
> 
> > On Wed, 2011-10-05 at 00:24 -0400, Tom Udale wrote:
> >> Hi all,
> 
> ..snip..
> 
> >> CVS.  For example:
> >>
> >>       *     406 Branch X
> >> *   |     405 default
> >> |   *     404 Branch X
> >> *   |     403 default: result of MERGE_TO_HEAD_DEC_25_2000
> >> |   *     402 Branch X
> >> *   |     401 default
> >> |   *     400 Branch X: MERGE_TO_HEAD_DEC_25_2000
> >> |   |
> >>
> >> etc...
> 
> ..snip..
> 
> >> So I simply add a merge via hg convert like this:
> >>
> >>        *     406 Branch X
> >> *    |     405 default
> >> |    *     404 Branch X
> >> *    |     403 default: result of MERGE_TO_HEAD_DEC_25_2000
> >> | \  *     402 Branch X
> >> *  \ |     401 default
> >> |    *     400 Branch X: MERGE_TO_HEAD_DEC_25_2000
> >> |    |
> 
> ..snip..
> 
> >> My question is, how is this going to come back to bite me?  I am far too
> >> ignorant about the inner workings of hg to fully predict how this can go
> >> wrong.  I know that the file manifests for each changeset are actually
> >> stored as deltas from the parents (with full snap shots every now and then).
> >
> > The details of how things are actually stored is irrelevant here. What
> > matters at the conceptual level is that Mercurial stores snapshots:
> > complete images of the state of your project at each commit. Mercurial
> > also stores the relations between all those snapshots as the changeset
> > graph. When you merge, you're merging three snapshots (local, other,
> > ancestor) according to that graph.
> 
> Thanks for your reply.  So are you saying then that at a conceptual 
> level (and I guess practical level) the snapshot at each commit is 
> completely independent from the relationship between commits? 
> Irrespective of changes in parents by convert, rebase or whatever, the 
> tools will maintain the original snapshot?

Yes. In other words, when you check out a revision, it will be exactly
the same as what you checked in. This, in my view, is the fundamental
law of version control.

> Am I correct then in surmising that when hg convert completely splices 
> in a new parent, it basically has to construct a manifest using the old 
> parent and then lay down completely new deltas at the new location based 
> on the state of the new parents - even if at the extreme it has to 
> specify a new file state for every file in the manifest (for example if 
> you spliced onto an unrelated repository)?

No, it's actually much simpler than that.

The storage layer is intentionally isolated from the upper-level details
like this. Mercurial says "store this snapshot" and revlog says "sure"
and figures out how to do that on its own.

Since convert already knows precisely what "revision 403" is (ie it
already has a snapshot), all it does in the splicemap is record the one
additional datum "btw, revision 400 is the second parent".

-- 
Mathematics is the supreme nostalgia of our time.