Changeset

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Aaron Bentley wrote:
>> I think it's not the changeset base that matters, it's whether the
>> current branch revision is an (possibly indirect) ancestor of the
>> changeset being applied.
> 
> 
> Actually, I'm talking about an exact patch. If cset.base_id ==
> branch.last_patch() then it should be completely possible to add the
> revision as just the next entry in revision-history. Think pull as
> opposed to merge.
> Otherwise if base is in the working trees ancestry, it gets added as a
> 'merged-revision' and a new commit needs to be created, with it as one
> of the parents.

the cset.base_id isn't restricted to being an ancestor of the cset
target revision, so that doesn't work.  I'd say the optimal changeset
base is the one that has the most text-ids in common with the changeset
target revision, because that should produce the shortest patch, but
always using branch.base would be helpful, since it would clearly
indicate what changes the merge would apply to the current code.

So
1. if the branch base is used as the changeset base, but it is not an
ancestor of the changeset target, you'll get improper pull behaviour

2. if the branch base is an ancestor of the changeset target, but a
different revision (say, the branch base's predecessor) is selected as
the changeset base, you won't get pull behaviour, even though you should.

> The other interesting trick with merging another persons tree is the
> following:
> 
> Me-  A - B - C
> #    |     \   \
> You- + - D - E - F
> 
> According to my understanding of what Martin has said, it should be
> possible that F is simply a 'pull' of C. Because C's ancestor is in the
> list of parents for E.

- From whose perspective?

If F is a pull of C, then I lose E from my branch revision history, and
I think that would be bad.

AIUI, E itself must be an ancestor of C for C to pulled.

If you mean that you should be able to pull F into your branch, I agree
with that.

> Another interesting possibility is that if you are merging a line of
> development like this:
> 
> Me-  A - B - C
> #    |         \
> You- + - D - - - E
> 
> In theory, you can do another way:
> 
> Me-  A - B - C
> #    |     \   \
> You- + - D - E - C
> 
> 
> Because the ancestor of C is a parent of E, according to Martin, you can
> pull it, rather than merging it.
> B->E has to update the tree so that it makes sense.

> 
> I'm not sure if I agree with Martin entirely, and it might be that I
> misunderstand what he was thinking.
> The problem is that when you 'merge' you pull in the changesets, not the
> tree state. In my head, since the state of the tree at E is not
> identical to the state at B, you cannot just plop C into Your branch.

This is why I keep saying the snapshots are important and the changesets
are just an optimization.

> For instance, it is definitely possible for 'D' to introduce a change
> that would conflict with C.

If you were doing that crazy thing, then the logical merge base would be
E, and since base==this, no conflicts are possible.

Here's some terminology I just invented that may be helpful:
"install a revision": copy all the texts, the inventory XML, and the
revision XML into a branch

'pull' installs revisions.  The current merge does not, but it could.

I see changesets primarily as a way we can install revisions.  Once we
have the revisions installed, we can do a merge to update the working
tree, so that it gets the changes introduced in those revisions.  That
merge operation can also update the branch metadata.

And there are two ways of updating the branch metadata:
If the merged revision has the branch base as an ancestor, then we can
update the revision-history.  Otherwise, we should update
merged-revisions or something, so the next commit can create a revision
that lists it as a parent.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwulr0F+nu1YWqI0RAkCzAJ9B3oWzWaP9zGF0yopPurqrvNPMlgCcDX6w
iQVAQ6Jby6IqP9Gn/n8XCOQ=
=MmJT
-----END PGP SIGNATURE-----