Changesets and multiple ancestors

[Martin Pool]

On 28 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > So I would say, "Yes, branch->branch merging will always be preferred",
> > but changeset merging can still get 90% of the job done.
> 
> It's not very satisfying to me.
> 
> I'd like changesets to be seamless, but it seems like if you always use
> changesets, you'll eventually get screwed.  Of course, sometimes
> 'perfect' is the enemy of 'good', and sometimes 90% isn't even half as
> good as 100%.

I'd like it to be possible to cooperate entirely using changesets
without any loss of functionality.  It is a little hard but I think it's
possible.

One option is to send a changeset that spans several revisions.  For
example this might run from some point on the mainline to the tip of
another person's feature branch; other people would be able to see that
the revisions were merged but potentially never find the exact text of
them.

(On the other hand, perhaps if the changes on the feature branch are not
intended to be public at all perhaps they should be cleaned away and
never mentioned in the submission.)

Another approach is to send multiple changesets, one per revision,
either in a series of mails or concatenated in a single mail.  This
would be more like a push over email.

> It seems we end up with two classes of ancestors: the ones in the branch
> revision history, which are expected to be present, and those listed in
> the revisions, which may or may not be present.

I think ultimately we may have to cope with references to revisions that
are not locally known.  By extension a branch may refer to revisions
that are no longer recorded anywhere at all.  Will this make things very
ugly or only a bit more complex?

-- 
Martin