To: gnu-arch-users@gnu.org
References: <20041107234609.7bf0abfe@delta.hk.office.outblaze.com>
	<tnxlldcbqm1.fsf@arm.com>
	<D4D5B1A3-31DC-11D9-B0B3-000393CFE6B8@spy.net>
	<1099995711.2900.84.camel@stargate>
	<1100306258.7511.56.camel@localhost>
	<20041113122841.GA13424@fencepost>
	<20041116081231.GS10330@patrick.wattle.id.au>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Mon, 22 Nov 2004 09:55:11 +0000
Message-ID: <tnxsm72dx8g.fsf@arm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Gnu-arch-users] Re: darcs vs tla
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: 3084
Lines: 68
Cameron Patrick <cameron@patrick.wattle.id.au> writes:
> Anyway, the first post that I can see describing a pure merge
> algorithm is here:
>
>     http://cp.yi.org/lurker/message/20030525.000938.4f48d03d.en.html

>From this message (written by Robert Collins): "The bad news: say
goodbye to star-merge (not needed), replay and update as 'merging'
tools."

Indeed, pure-merge would be useful but star-merge will still be
used. Take for example the Linux kernel development. There are around
3000 changesets between releases. If I upgrade my branch, I wouldn't
like to see all those chanso be useful if arch would
have an option to specify the author of the patch, other than the one
doing the commit. That's also useful if someone would like to create a
mirror of a non-arch repository (the Linux kernel?) and preserve the
author.

The 'star-merge --three-way' (*not* the standard one) algoritm can be
modified to cope with cherry-picking. The common ancestor of 2
branches is the last revision before the first 'tla missing' reported
revision between these branches (maybe it already does this). If a
patch was cherry-picked from one branch into the other branch,
'star-merge -t' would report a conflict in the files modified by the
cherry-picked patch. It is likely that the conflicting parts are the
same or, at least, have some common lines. This can be easily solved
manually or by using a smarter diff3 tool which eliminates the common
lines in the conflicting parts (though it might find similarities
between other conflicting parts not modified by the cherry-picked
patch, but I don't see this as a problem).

A more darcs-like way of 'star-merge -t' would be to apply the
cherry-picked patches to the common ancestor before the diff3
merging. If the patch fails to apply, that's fine since we can
manually fix the conflicts in the star-merged tree.

The same result is actually achieved by darcs using the patch
commuting operators. If there are not cherry-picked changes, the
'darcs pull' and 'star-merge -t' are equivalent regarding the result
on the merged tree (darcs doesn't lose the individual changes
though). By successive commuting, darcs moves the cherry-picked
changes before the unmerged ones thus creating a real common ancestor
with all the changes merged in either direction. Unlike replaying the
cherry-picked patches onto the common ancestor, darcs' creation of the
common ancestor always succeeds because if 2 patches cannot commute,
they were both merged when cherry-picked (patch dependency tracking,
you can find situations where this is annoying, i.e. adding some
definitions to a C header file, sorted alphabetically). Another
difference with darcs is that adjacent changes to the same file are
considered independent and they can be commuted (I personally prefer
the arch way of knowing if the context of a patch changes).

Catalin


_______________________________________________
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/