Changeset

[Martin Pool]

On 29 Jun 2005, John A Meinel <john at arbash-meinel.com> 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
> 
> So installing a revision does not alter the revision-history or the
> working directory? Just creates entries in the various stores?

Yes.  But installing a revision will normally be done as the first stage
of some larger operation that's more useful to the user, and that will
end up updating the working directory and either pending-merges or
revision-history.

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

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

We're using a diff-like format because they serve two purposes: human
review, and also reproducing revisions.  diffs are good for human
review.  (darcs's almost-diff format is not nearly as good in my opinion
because it has no context.)

Other systems such as arch and bk keep these separate: a person sends a
patch indicating what they want to change, and if it's OK the recipient
pulls from a nominated location.  It avoids overloading changesets and
makes the vc author's life easier, but is inferior in several ways: what
is pulled is not necessarily what is reviewed; people must be able to
publish trees to send changesets, not just to send mail; if the archive
is offline I may have the changeset but not be able to merge it; the
code to send mail needs to know where it will be published; etc.

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

Yes, if we didn't want human review we could use a more compact and
cleaner format.  That'd be good for a smart server, or for people who
want to send changesets by mail but are happy for them to be blobs.

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

Yes... and also the *means* for them to get 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 don't think you necessarily do.  Only if you want me to know the
details of B and C.

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

You need a way to find out what the recipient already has.  It's OK if
this is too conservative (and they actually have something later.)
Typically this will be a revision from the recipient's last published
tree.

Suppose we have John and Mary collaborating purely over email without
either being able to publish an archive.  It seems hard to choose a
basis revision for sending changesets.

At the worst, we can use Null and always send the complete tree.  This
makes them large and hard to review in the mail client, but once the
revision is installed they can see a straightforward diff of what will
be merged.

But we can do better.  Mary may keep a branch holding the last version
of John's work that she's received; she applies his changes into that
and then merges across into her own working tree.  She can send John
changesets based on her idea of his tree.

-- 
Martin