Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults

[Tom Lord]

    > On Nov 9, 2003, at 14:47, Colin Walters wrote:

    > I'd actually like to go a bit farther, and have just "tla star-merge"
    > default to star-merging from the last fully-qualified revision you
    > tagged from.  

That is surely not what you mean.

In most cases, that would simply undo a lot of changes.   I can figure
out your meaning, but it's helpful when thinking about these things to 
try to speak precisely, because that can lead to clearer thinking.

I think that what you really mean is closer to this:

   Let V be the fully qualified version name which is the 
   tree-version of the tree being merged into.

   Let TR(V) be the latest revision in V that the tree is up to date 
   with.

   Let TRTA(TR(V)) be the most recent ancestor of TR(V) which is
   a continuation revision.

   Let CVR(TRTA(TR(V))) be the fully qualified revision name of the
   revision of which TRTA(TR(V)) is a continuation (the revision named
   in the CONTINUATION file of TRTA(TR(V))).

   Let V(CVR(TRTA(TR(V)))) be the fully qualified version name of
   the revision CVR(TRTA(TR(V))).

   Then V(CVR(TRTA(TR(V)))) is the default FROM parameter of the
   star-merge command.

The documentation for star-merge would actually have to translate that
into english.   Yikes.

Not to mention that, for example, computation of TRTA(TR(V)) involves
new server round-trips.

It seems to me like what you are really trying to carve out is a
particular example of what my be done for:

        % overarch star-merge-from-upstream

In other words, instead of trying to get `tla star-merge' to do this
because (you assert) "it's the common case", perhaps the better thing 
to do is to introduce a new layer of abstraction for
`star-merge-from-upstream' and then figure out what to put behind it.


-t