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

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

Re: [Gnu-arch-users] Re: NEW: three-way merges / conflict markers


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: NEW: three-way merges / conflict markers
Date: Wed, 24 Sep 2003 12:41:01 -0700 (PDT)

    > From: Samuel Tardieu <address@hidden>

    > Tom> * yours
    > Tom>            that base revision with the undo changeset applied to
    > Tom>            it.  In other words, the project tree as it was when
    > Tom>            `undo' was invoked.
    > Tom> (It gets a little weirder if I muck with `tree-version' but
    > Tom> hopefully you get the idea.)

    > I think mucking with tree-version is quite a common scenario:

    > - make some changes
    > - tla undo
    > - make other changes, commit
    > - tla redo

(That doesn't change `tla tree-version' but I see your point.)

    > You can't compute the "yours" tree here if the undo changeset doesn't
    > apply now that the tree version has changed because of the commit. And
    > if you don't have the "yours", you can't do the three-way merge.

The ORIG tree used to compute the changeset generated by undo still
serves as a useful (and clean) ancestor here.   

You're right that I was wrongly assuming that that ORIG tree would
automatically be the same as the latest revision that the project tree
is up-to-date with.

But if `undo' added a comma-file to the changeset naming that ORIG,
then it's:


        ancestor        := ORIG

        mine            := the current target tree

        yours           := dopatch ORIG UNDO-CHANGESET


(That reduces to what I first said in the case that you take the
commit out of your scenario.)

-t





reply via email to

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