[Gnu-arch-users] Re: practical questions of archive ownership

[Andrew Suffield]

On Wed, Oct 01, 2003 at 03:33:59PM +0900, Miles Bader wrote:
> Andrew Suffield <address@hidden> writes:
> > Here you want a patch queue manager. Your central archive then belongs
> > to a program which does all the merging (conflicts are "handled" by
> > bouncing the group of changes - no conflict resolution occurs in this
> > archive).
> 
> I'm not sure why I would want this; it sounds like to sanely be able to
> resolve `bounced' conflicts, each developer would have to maintain
> exactly the same update/resolve discipline with a patch-queue manager
> system as with the manual case, only the commit step would be different
> latency compared to a normal commit it seems like it would have a
> greater chance of incurring more conflicts.
> 
> Or is the theory that conflicts are rare and so one must only
> update/resolve against the canonical branch when they happen?

Partly - but also, "commits" to a managed branch are a higher-level
operation than "tla commit". They will normally be comprised of
multiple changesets.

It may help to think of Tom's prism-merge method, but with the actual
merge part taken out and handed over to an automated system (I think
that patch queue manages can be a bit more broad than prism-merge,
though).

Here's a practical example. You're working in your own archive; you've
prepared a group of changes that you want to commit to the
mainline. Without a patch queue manager, you have to:

 - get or replay a tree which is up to date with the mainline
 - replay the changes from your own branch into this tree
[- check that it builds, and that none of the changes other people
   have made break your changes]
 - commit this tree

This procedure, while not overly complicated, gets boring very
fast. The simplest form of patch queue manager automates this.

> system as with the manual case, only the commit step would be different
> latency compared to a normal commit it seems like it would have a
> greater chance of incurring more conflicts.

That's where the "queue" part comes in. Once your change has started
its trip through the system, its place in the queue is already
allocated; if it passes whatever tests are involved, it will go in
that position. Since the sequence is known up front, the system should
immediately be able to report obvious (same lines) or likely (same
file) conflicts, and since the sequence isn't disturbed from what it
would be if you committed directly, it shouldn't make conflicts more
likely.

[This really starts to come into its own when you have people who
aren't allowed to commit directly, but instead need their patches
reviewed by somebody else first (gcc and mozilla are good examples, as
is any project where a single person is responsible for merging
patches). In these scenarios, a patch queue manager can actually speed
up the process significantly by running test merges and builds in the
background, in advance].

Now, if you have a pile of spare processing time available, you can
start getting clever. In the background (while you're doing other
things), the system can be experimenting with merging and building the
mainline with the current state of your changes. If a conflict occurs,
it can warn you in advance (while you're still working on your own
branch); when you come to commit to the mainline, it might already
have a merge prepared, tested, and ready to install into the archive.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature