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

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

Re: [Gnu-arch-users] Re: <<< conflict markers


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: <<< conflict markers
Date: Thu, 15 Apr 2004 14:47:26 -0700 (PDT)

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > > One could understand `update' as:
    > > 
    > >     TMP = get YOURS
    > >     delta-patch --dir TMP ANCESTOR
    > >     . := TMP

    > > but with an implementation that optimizes it, often to:

    > >         [1] undo ANCESTOR
    > >         [2] replay ANCESTOR ... YOURS
    > >         [3] redo

    > If we ever want tla to behave properly when tagging and commits are 
    > mixed, 

Stop there.  There's different values for "properly" there.


    > it's essential to follow ancestry, not namespace relationships. 

It may be desirable to permit both options but it is essential to
provide the option of using namespace relationships.


    > So we need to let go of the idea that replay and update are related, or 
    > else make replay follow ancestry.

Wrong.   It would be good to make the "general merge" engine I
sketched that can handle all compositions of history-sensitivity and
merge primitives.   It's good to identify subsets of that space which
capture particularly common situations (like `star-merge').   It
_might_ be good to make it easier for particular production lines to
to pick which customized merge operators they want to make most
convenient by giving them a distinct name.

But the existing operations are pretty good as they are.   You want to
add new ones to the toolbox more often than you want to melt down the
hammers to make screwdrivers.



    > However, I can imagine performance improvements if we were to add "get 
    > --clobber" to our quiver.  get --clobber would transform the current 
    > project tree into the named revision, by overwriting files that differ 
    > (and adding, deleting as appropriate).

    > Then we can do:

    > tla changes --output ,,tmp
    > tla get --clobber YOURS
    > tla dopatch ,,tmp

We already have `get --clobber' in the form of a special case of
`delta-patch'.

Modulo one pending bug, merging into local trees does a pretty good
job of handling non-source files reasonably.  You have to be careful
not to mess that up to much when deploying "get --clobber".

-t





reply via email to

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