To: Anand Kumria <wildfire@progsoc.org>
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>
	<pan.2004.11.09.14.42.42.768933@progsoc.org>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Tue, 09 Nov 2004 15:05:27 +0000
In-Reply-To: <pan.2004.11.09.14.42.42.768933@progsoc.org> (Anand Kumria's
	message of "Wed, 10 Nov 2004 01:42:44 +1100")
Message-ID: <tnxpt2nrrk8.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
Cc: gnu-arch-users@gnu.org
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: 2442
Lines: 52
Anand Kumria <wildfire@progsoc.org> writes:
> On Tue, 09 Nov 2004 10:36:36 +0000, Catalin Marinas wrote:
>> 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.
>
> Ah, yes - something that bugged me today after a star-merge; all my
> conflicts were at the end of files. I'm guessing that that is a problem
> with diff/patch? Does darcs contain it's own version of these, or call
> out? Perhaps it uses different options which arch should pick up?

Darcs uses an internal algorithm similar to diff for creating the
changes but they are in a different format and it doesn't use the
patch tool for applying the patches.

>> 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.
>
> Without ids of some sort, how can darcs determine that P2 is modifying the
> same file that P1 renamed? Are you saying that on commit P2 would be
> stored as a modification on the original file (P1 filename) but at a later
> point in time?

P2 is stored as a modification to the latest file. Let's say you have
a file called aaa.c which is present in both the main tree and on a
branch. P1 renames this file to bbb.c in the main tree. P2 adds some
lines to the bbb.c file in the main tree. If you apply P1 and P2 on
the branch, in this order, everything would be fine. If you only want
to apply P2, darcs notices that P1 is not present and will commute the
two patches to P1' and P2' so that P2' can be applied before P1' but
preserving the file changes. P2' will be similar to P2 only that it
changes the aaa.c and not bbb.c file. You can later apply the P1 on
the branch (in fact, P1' will be applied) and rename the file to
bbb.c.

Have a look at the darcs' manual for the theory of patches.

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/