Changeset

[Martin Pool]

On 29 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

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

Yes, that's exactly what I was thinking.  "install" is a pretty good
word.

So the first step in taking in any other work is to install the incoming
revision into our repository.  If we're coming from a branch we can copy
it across; if we're accepting a mailed changeset then we need to
reconstruct it by applying the changeset to its base revision.  As Aaron
says the changeset is just an optimization so as to transmit less data
and make it human-reviewable.

One reason to install the changeset is that we can also install the gpg
signature by the original author and verify that at any later point,
without needing to go back to the mailed format.

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

(Maybe "branch head" rather than "branch base"; at any rate the last
thing in revision-history.)

I think the default should be to do it automatically as said, but I can
imagine people wanting to choose either method in particular cases; or
even perhaps to leave it floating around as an "unmerged head" (though
a good UI for that is unclear.)

-- 
Martin