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

[Colin Walters]

On Sat, 2003-11-08 at 21:57, Tom Lord wrote:
>     > 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.

Right.  I meant "fully-qualified version".

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

Instead of this, I chose to simply look at the base-0 revision and see
if it's a continuation.  If it is, we use that.  Otherwise we barf.

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

I chose to say, 
"If FROM is not given and no separate archive is specified, FROM will be
the last tagged revision"

That should probably read,

"If FROM is not given, no separate archive is specified, and the 
base-0 revision is a continuation, FROM will be
the latest revision of the version of that continuation."

(And it does now as of patch-52 in my archive)

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

Just one in my implementation.  And if TO is on a local machine (as I
think the common case is), then it should be quite cheap.

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

I think my solution is what to put behind it.

signature.asc
Description: This is a digitally signed message part