Date: Thu, 28 Oct 2004 09:55:15 -0700 (PDT)
Message-Id: <200410281655.i9SGtFwk084767@xl2.seyza.com>
From: Thomas Lord <lord@emf.net>
To: Matthieu.Moy@imag.fr
In-reply-to: <vpqoeinq0aw.fsf@ecrins.imag.fr> (message from Matthieu Moy on
	Thu, 28 Oct 2004 00:11:03 +0200)
Subject: Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in
	proposal
References: <20041025210724.GA19744@merconline.com>
	<200410272144.i9RLiYnd074868@xl2.seyza.com>
	<vpqoeinq0aw.fsf@ecrins.imag.fr>
Cc: gnu-arch-users@gnu.org, jblack@merconline.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: 1335
Lines: 39

    > From: Matthieu Moy <Matthieu.Moy@imag.fr>

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

    > Wouldn't it be better to let (a future version of) tla maintain this
    > file, and integrate it in the arch protocol instead of some user
    > convention?

The GNU mainline integrator, according to the rules, only ever has to
perform two kinds of merges to deal with contributions.  Both are
simple star-merges followed by log pruning.  The log pruning varies
slightly in the two cases.

Yes, those merge operations can and eventually should be automated,
and they can update the =merged file accurately AND be
history-sensitive to the contents of that file.   

Jblack's conundrum about branches A, B, and C in the OP of this
thread: C's problems would be solved by using these new mythical merge
commands (which are perhaps little more than two new options to
star-merge).

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