Date: Wed, 10 Nov 2004 12:47:30 -0800 (PST)
Message-Id: <200411102047.iAAKlUmv093629@xl2.seyza.com>
From: Thomas Lord <lord@emf.net>
To: catalin.marinas@arm.com
In-reply-to: <1099996596.2900.96.camel@stargate> (message from Catalin Marinas
	on Tue, 09 Nov 2004 10:36:36 +0000)
Subject: Re: [Gnu-arch-users] Re: darcs vs tla
References: <20041107234609.7bf0abfe@delta.hk.office.outblaze.com>
	<tnxlldcbqm1.fsf@arm.com> <877jowbl8w.fsf@tleepslib.sk.tsukuba.ac.jp>
	<200411082327.iA8NRVMB084815@xl2.seyza.com>
	<1099996596.2900.96.camel@stargate>
Cc: gnu-arch-users@gnu.org, stephen@xemacs.org, timw@outblaze.com
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2775
Lines: 66

    > From: Catalin Marinas <catalin.marinas@arm.com>

    > On Mon, 2004-11-08 at 23:27, Thomas Lord wrote:
    > > So: does Darcs' merge operators (the deep distinction it has from
    > > arch) really "add value"?  at scale?   What's up with those?   Does
    > > anyone actually /know/?

    > What the darcs operators can do is happily merge a patch which adds some
    > lines at the end of an existing patch (which is not merged). Arch would
    > fail this because the diff context contains the patch which is not
    > merged. This might not be good for C language files but might be OK for
    > makefiles.

That makes sense.  That's an edge-case of variance adjustment that
doesn't stray too far from the "semantic pun" of ordinary diffs.
Seems like a long way to go for just that --- but at least that's a
special case where variance adjustment pays off.


    > Another interesting thing the operators remove is the need for file ids.
    > If the P1 patch modifies a file's name and P2 adds some text to this
    > file, P2 can be properly merged into a tree which does not contain P1
    > because the commutation operators would change the P2 patch so that it
    > applies the changes to the original file name.

I don't think that eliminating the need for file ids is properly
attributable to the commutativity logic and variance adjustment done
by darcs.

Rather: the non-need for file ids is a consequence of how history is
treated and that, in turn, implies limits on the kinds of merging that
is possible.   

For example, if what you report is true, then darcs can not easily
accomplish a particular form of cherry picking (picking from a branch
whose ancestry is irrelevant or unclear and/or unavailable)  if said
cherry picking is attempted in the face of renames.

And that that is true is reinforced by conversations we had during the
"common changeset format discussions" which got bogged down in (absurd
on the face of them) disagreements about what history could be counted
on as being available.

I opened my mind for this darcs thread and it looks like I'm going to
wind up where I started:  they have some rather esoteric merge
technology that could be added to arch;  aside from that, they are
missing too much.   Would have been better if darcs had, in the first
place, been done as an extension to arch.   Meanwhile, their novel
merge tech is "on the list of things todo" but not a high priority.

(Does that sound insulting towards Darcs?   It doesn't at all if you
regard darcs as a short-term R&D exploration.)

-t


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/