Changeset

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>
...

>
> 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.
>

I think we need a terminology clarification here.
> 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.

Me-  A - B - C
#    |     \   \
You- + - D - E - F

Yeah, I think I got the order backwards. The above doesn't seem to work,
but this should:

Me-  A - B - - - E - F
#    |     \   /
You- + - D - E - F

So if I have merged your work, you can simply pull my merge back across.

...

>
> 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

So installing a revision does not alter the revision-history or the
working directory? Just creates entries in the various stores?

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

I think pull should install revisions, and then update the working tree
and ancestry to include the newly installed revisions.

Merge should install revisions, and update the working tree, and some
meta information to indicate that a merge has been done. But holds off
on the final commit and update of ancestry.

This means that after a pull, you would have a new revision-history,
which would include the pulled revisions. After a merge, you would have
a list of "merged-revisions" and a new working tree.

>
> 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.

I see changesets as probably the opposite. They are used to alter the
working tree, and if possible, install revisions. Otherwise why are we
using a diff-like format.
If you want to update the stores without altering the working tree, it
seems to me that there would be better formats.

A changeset to me is a way of communicating to another human that I made
some changes, and would like to see them incorporated.

It seems to me, that if a changeset is used to install revisions, then
we have the problem of needing to include *lots* of meta information.
Especially for roll-up changesets. To give you A->B->C->D I need to give
you the states for B & C, not just the delta from A->D.
I can give it to you as deltas A->B, B->C, C->D, and assume that you
have A, and can thus generate the exact state for B, C, and D.

If all I do is modify the working tree and copy the revision XML into
the branch, then future merges can understand what has been merged, to
avoid remerging something (think of the case where you merge me, and
then explicitly remove my changes, they should stay gone, right?)

John
=:->

>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050629/bf5987ea/attachment.pgp