Subject: Re: [Gnu-arch-users] Re: darcs vs tla
From: Catalin Marinas <catalin.marinas@arm.com>
To: Thomas Lord <lord@emf.net>
In-Reply-To: <200411102047.iAAKlUmv093629@xl2.seyza.com>
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>
	<200411102047.iAAKlUmv093629@xl2.seyza.com>
Content-Type: text/plain
Message-Id: <1100167902.2788.38.camel@stargate>
Mime-Version: 1.0
Date: Thu, 11 Nov 2004 10:11:43 +0000
Content-Transfer-Encoding: 7bit
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: 3067
Lines: 65
On Wed, 2004-11-10 at 20:47, Thomas Lord 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.
> 
> 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.

But there are also cases where I would prefer to see the context of the
patch and not just merge it without reporting a conflict.

> 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.

You are right. Darcs doesn't properly work with unrelated repositories.
If you only want to cherry-pick a patch from such a repository, darcs
will try to commute it until it reaches the beginning of the history
(pulling the patches which are dependent) and then commute it with the
patches in the repository it will be applied to. I did a simple test and
the conflicting file was simply deleted (probably I use an older version
of darcs).

In darcs, any patch depends at least on the file creation patch which
would automatically conflict with the patch creating the same file in an
unrelated repository. This is the same for arch, unless you have the
same file id in both repositories (well, in arch at least you have a
workaround).

> 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;

Maybe time will tell if this merge technology brings many benefits. I
can think of cases where it is unsafe (see the beginning of this
message). On the other hand, darcs can notify you that the patch
actually depends on a different patch and can pull both at a time. Arch
could track this but it is time consuming with the actual structure of a
changeset (the log or other file should have some information about the
files modified and the corresponding line numbers, without the actual
data added/removed). It could use the revision library as well but it
still means retrieving all the patches to create the full history in a
revlib. Anyway, darcs is not so good at this since it loads all the
patches into memory.

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/