Date: Wed, 27 Oct 2004 14:44:34 -0700 (PDT)
Message-Id: <200410272144.i9RLiYnd074868@xl2.seyza.com>
From: Thomas Lord <lord@emf.net>
To: jblack@merconline.com
In-reply-to: <20041025210724.GA19744@merconline.com> (jblack@merconline.com)
Subject: Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
References: <20041025210724.GA19744@merconline.com>
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: 2434
Lines: 64

    > From: jblack@merconline.com (James Blackwell)

    > I keep thinking about the part of Tom's release proposal as it relates to
    > patch-log pruning.

    > I can't quite get my mind around the log pruning. As I understand things,
    > this will make foreign trees difficult, if not impossible to manage. The
    > problem goes along these lines.

    > First, assume trees A, B and C. B regularly merges from A, but in the
    > process prunes the patch-logs.  C replays/updates/star-merges from B.

    > Things still look reasonably sane, right?

    > But now imagine what happens if C attempts to replay from A after
    > replaying from B. 

Each merge into mainline, whether casual contribution or one step of a
cascade, is the one and only merge of the source version of those
changes into mainline.   In other words, for some arch version name, 
under the rules of the spec, that version name gets merged into the
mainline exactly once (and never again after that).

So, in some sense, what you suggest that C is doing in your scenario
is crazy: C should have no reason to do that, probably.

But how can C detect that A has been merged into B and thereby avoid
attempting to redundently merge in A, given that B does not retain A's
log?   It's appropropriate that B doesn't contain A's patch log
because, really, the only information here is a set of version names:
those which have been merged into B.   We don't need or want
individual patch log entries --- just the list of versions merged.

One line per merged contribution won't add up to excess for a long
time.

So: how about we modify the process so that we maintain a file

	./src/tla/=merged

Each time a (log-pruned) version is merged into tla, it's version name
will be appended to that file.   No version name should appear twice
in that file.

C can build an interesting tree by starting with a set of
"works-in-progress" submission branches.   To merge from B: C gets a B
tree, subtracts out the =merged versions from the works-in-progress
set, then merges in from all of the works-in-progress branches,
pausing for conflicts.   When A is merged into B, it will appear in
=merges, and so C will know to not merge it anymore.


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