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

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

Re: [Gnu-arch-users] Status of global and tree aliases


From: Tom Lord
Subject: Re: [Gnu-arch-users] Status of global and tree aliases
Date: Tue, 20 Jul 2004 16:14:44 -0700 (PDT)

    > From: address@hidden (James Blackwell)
    > Tom Lord wrote:

    >> That's one of the significant problems I see with jblack's approach:
    >> it will interact oddly with merging, probably often not in the
    >> intended ways.

    > There would be a conflict in =meta-info, much the way I'd expect a
    > potential conflict with =tagging-method.

That's an unfortunate comparison.   If I'm merging from an upstream or
downstream who's following the same process at me then conflicts are
entirely unnecessary because there is a deterministic and easily
stated rule for resolving them.  The same is not true of conflicts in
=tagging-method.


    > Most of the time, things will "just work". Occasionally, if
    > people add the same alias in two branches at the same time, then
    > merge them, they merge a simple conflict.

I'm not convinced by such statements that you've thought through many
scenarios or uses for this.

In general, it's a case where you want to implement feature A but you
don't seem to have stopped to consider whether there is a feature B
that wouldn't be terribly more difficult to implement and that would
provide not only A, but much more besides.


    > > For example, suppose I am your upstream.  Your version has an alias
    > > `upstream' defined that points to me.   If I cycle my archive, I
    > > should be able to commit a change that, when merged, will update your
    > > `upstream' (though perhaps with protection -- such as asking you to
    > > confirm the change before it is committed).

    > The tree alias thing should be able to handle this, and sure we could
    > later add on an internal to tla list of 'special' variables 
    > that if they're changed, causes tla to bomb out unless a flag is given.

"Special" variables?  "unless a flag is given"?    This is the kind of
vague design effort that leads to the disease known as "creeping featuritis".

    > Could you do this without furth?

What are your engineering reasons for objecting to furth?

-t





reply via email to

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