On Wed, 30 Jan 2002, Larry McVoy wrote:
> No. What you described is diff/patch. We have that already and if it
> really worked in all the cases there would be no need for BitKeeper to
> exist. I'll be the first to admit that BK is too pedantic about
> change ordering and atomicity, but you need to see that there is a
> spectrum and if we slid BK over to what you described it would be a
> meaningless tool, it would basically be a lot of code implementing
> what people already do with diff/patch.
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?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:20 EST