gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge an


From: Tom Lord
Subject: Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults
Date: Sat, 8 Nov 2003 20:26:12 -0800 (PST)

    > From: Colin Walters <address@hidden>

    > On Sat, 2003-11-08 at 22:55, Tom Lord wrote:

    > > Well, an overarch abstraction might decide to add an "=3Dupstream"
    > > notation in {arch}, as one possibility.  Or, for that matter, more
    > > than one of them.

    > Ok, I would accept that.  This brings us back to my "clone" idea; how
    > about having "tla clone" create this file by default?  This would be
    > slightly ugly because it would mean a clone operation would have to be
    > both a base-0 which is a continuation, and then a patch-1 adding the
    > {arch}/=3Dupstream.

Not necessarily.  Not if `commit --continuation' reappears, for one
solution.  Other solutions that don't need a project tree (which
commit would, but that might not be a bad thing for a clone command)
also exist.


    > > Otherwise, we can work on that "other solution" but isn't the pony a
    > > higher priority?

    > Ah...parse error?

You wished for a solution that didn't involve tracing ancestry.  I
suggested some ways to do that but, if you didn't like those, I was
suggesting that perhaps the wish was a fantasy (like "and, I'd like a
pony").


    > BTW, you didn't answer my question about the situations in which it
    > would cause problems.

When there are tags more recent than base-0.   This is an example of
one of those "edge cases" you sometimes hear Larry McVoy talking
about.   So far, in arch, we've got those under pretty good control so
I'm not too enthusiastic about a patch that changes that.


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]