Message-ID: <41803AEC.1050209@panoramicfeedback.com>
Date: Wed, 27 Oct 2004 20:18:52 -0400
From: Aaron Bentley <abentley@panoramicfeedback.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
MIME-Version: 1.0
To: Thomas Lord <lord@emf.net>
Subject: Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
References: <20041025210724.GA19744@merconline.com>
	<200410272144.i9RLiYnd074868@xl2.seyza.com>
In-Reply-To: <200410272144.i9RLiYnd074868@xl2.seyza.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org
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: 2324
Lines: 50
One of the features of Arch I really like is the history-sensitive 
merging.  This process breaks history-sensitive merge commands.

I happen to know that 
lord@emf.net--gnu-arch-2004/tla--devo--1.3--patch-7 is a merge of 
changes I made in my tlasrc--devel--0.2 tree.  But since the only 
patchlog is the one for lord@emf.net--gnu-arch-2004/tla--devo--1.3, I 
cannot use replay --skip-present 
lord@emf.net--gnu-arch-2004/tla--devo--1.3 to apply the latest changes 
to my tree.  Ironically, very few people aside from me will have this 
problem.  James will, since he merged me.

But this process essentially penalizes people for contributing code.

These problems do not necessarily go away if we change to a 
one-version-per-merge model.  It's quite likely that my submissions will 
not be originated in the version that I submit for merging.

Many of the patches I submitted for 1.2.2 needed work before they could 
merge cleanly.  So five of my submissions were from tla--submit--1.2.2. 
    I think we can pretend that it was a submission version as described 
in the plan.  But it's quite reasonable that my tlasrc--devel--0.2 tree 
would have no patchlogs for tlasrc--devel--0.2.  The patches were either 
developed there, or entered it by a different route.

Your =merged idea provides a way to determine what the direct merges 
are-- kinda-sorta.  It's not guaranteed to be right, because it's not 
guaranteed that all of the revisions in the version were, in fact, 
merged, and that no revisions have been added since the version was 
merged.  But I'm arguing that the indirect merges are important also, 
and so =merged is not an adequate solution.

Let's end with a threat: if you go ahead with =merged, I will do my 
level best to support it in Fai.  For cases where the merged version has 
patchlogs in the tree, I can implement a "replay --skip-present" 
workalike that will use the changeset contents to determine whether a 
patch should be applied.  That will make Fai a significantly less broken 
tool for developing tla than tla itself.  You don't really want that, do 
you? :-)

Aaron


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