Changeset

[Aaron Bentley]

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

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.

Okay,
changeset target: the revision the changeset produces
changeset base: the revision that the changeset must be applied to in
order to produce the changeset target.  (its id is cset.base_id)
branch base: the last revision in the revision history of the branch

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

Right.

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

That's right.  It's an operation perfomed by both pull and commit
(though they do different things to acquire the revision data that they
install).

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

Yes, pull also updates the working tree and branch metadata.  I was just
contrasting with merge.

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

The ancestry will be handled as normal.  The meta-info just affects the
revision XML that gets committed.

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

Right.  Now to confuse matters, the UI might automatically do a merge
when it can't do a pull.

>> 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 think I was unclear here about the level I was talking about.

For the command "bzr merge /path/to/changeset", you

1. install the changeset target
2. merge the changeset target
3. update the merged-revisions data

> I see changesets as probably the opposite. They are used to alter the
> working tree, and if possible, install revisions.

When would they not be able to install revisions?

> Otherwise why are we using a diff-like format.

Because people would like to be able to see what changes would be made.

> If you want to update the stores without altering the working tree, it
> seems to me that there would be better formats.

There are few formats with the broad tool support and mindshare of
unified diffs.

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

Right.  So when you submit a changeset, you can use the other person's
branch base as your changeset base.  That doesn't mean that they will be
able to cleanly apply it.

By requiring that the changeset base always be known to the receiver, we
gain the ability to do three-way merging, which is better than
patch+diff, because three-way merging can be done using patch+diff with
custom options, or diff3, or wiggle, or meld, or pretty much any merge tool.

This also simplifies changeset handling, because if changesets are only
ever applied to their exact base, there can never be ambiguity or conflicts.

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

No, I think Martin's latest proposal is almost exactly right.  What data
is missing?

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

If you want to give me B and C as well as D, you have to communicate
them somehow.  If you just want to give me D, you can send A->D,
assuming A is a revision I have.

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

Yeah, and the same holds true if you install the revision first, and
then do a merge into the working tree.

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

iD8DBQFCwwDx0F+nu1YWqI0RAh3OAJ95IXSH2fH/Pjxcn3X1PhUSOX/v4QCeImWQ
/RQmwuK+1y9waVyPukQA6w4=
=mspW
-----END PGP SIGNATURE-----