Re: A modest proposal -- We need a patch penguin

[Larry McVoy <lm@bitmover.com>]

On Wed, Jan 30, 2002 at 07:48:35PM +0100, Ingo Molnar wrote:
> eg. i sent 8 different scheduler update patches 5 days ago:
> 
>  [patch] [sched] fork-fix 2.5.3-pre5
>  [patch] [sched] yield-fixes 2.5.3-pre5
>  [patch] [sched] SCHED_RR fix, 2.5.3-pre5
>  [patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
>  [patch] [sched] entry.S offset fix, 2.5.3-pre5.
>  [patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
>  [patch] [sched] compiler warning fix, 2.5.3-pre3
>  [patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3
> 
> these patches, while many of them are touching the same file (sched.c) are
> functionally orthogonal, and can be applied in any order. Linus has
> applied all of them, but he might have omitted any questionable one and
> still apply the rest.
> 
> how would such changes be expressed via BK, and would it be possible for
> Linus to reject/accept an arbitrary set of these patches?

There is a way to do this in BK that would work just fine.  It pushes some
work back onto the developer, but if you are willing to do it, we have no
problem doing what you want with BK in its current form and I suspect that
the work is very similar to what you are already doing.

In your list above, all of the patches are against 2.5.3-pre5.  If you did
the work for each patch against the 2.5.3-pre5 baseline, checking it in,
saving the BK patch, removing that changeset from the tree, and then going
onto the next change, what you'd have is exactly the same set of patches
as you have no.  Literally.  You could type the appropriate command to BK
and you should be able to generate a bit for bit identical patch.

In BK's mind, what you have done is to make a very "bushy" set of changes,
they are all "side by side".  If you think of a graph of changes, you started
with

			[older changes]
			      v
			  [2.5.3-pre4]
			      v
			  [2.5.3-pre5]

and then you added one change below that, multiple times.  If you were to
combine all of those changes in a BK tree, it would look like

			[older changes]
			      v
			  [2.5.3-pre4]
			      v
			  [2.5.3-pre5]
  [sched1] [sched2] [sched3] [sched4] [sched5] [sched6] [sched7]

and BK would be happy to allow you to send any subset of the sched changes
to Linus and it would work *exactly* how you want it to work.  If we could
get people to work like this, there are no problems.  Just to make it really
clear you would do this

	for p in patch_list
	do	bk vi sched.c	# that will lock it if isn't
		hack, debug, test
		bk citool	# check it in and make a changeset
		bk makepatch -r+ > ~/bk-patches/patch.$p
		bk undo -fr+	# get back to the same baseline
	done

Here's what people actually do.  They make the first change, then make
the second change in the same tree that already has the first change,
and so on.  BitKeeper faithfully records the linear sequence of changes
and enforces that the changes propogate as that linear sequence.  You can
skip some at the end but you can't skip any in the middle.

In your particular case, we really need out of order changesets to allow
the second type of work flow and cherry picking.  However, a fairly common
case is that the changes are all in unrelated files and *even then* 
BitKeeper enforces the linearity.  That's the problem I think we need to
fix first, it's not a complete solution, but it is the 80-90% solution.
Until we give you a 100% solution, you have to realize that you are making
side by side changes and actually do it that way.

If any of this is not clear to anyone, please speak up and I'll try and 
draw some pictures and add some explanation.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm