On Thu, 31 Jan 2002 00:16:13 -0500,
Rob Landley <landley@trommello.org> wrote:
>Linus himself seems to have denied this assumption. Just because a
>downstream developer took two months to come up with a subsystem and did
>eight hundred seperate checkins of which only maybe 20% of the code made it
>into the final version, does NOT mean that Linus cares. That level of detail
>IS more information, but there's a limit to how much information you want
>before it becomes cruft in Linus's tree.
I agree with Rob on this. My PRCS tree for 2.4 has 950+ patch sets in
it but there is no way I would inflict that level of detail on the rest
of the world. I follow the model of check in often, even if it does
not work, so I can backtrack and take another branch if the code hits a
dead end.
Lots of small checkins and branching means a lot of history which is
useful to me but to nobody else. When I release a patch I pick a start
point (base 2.4.17, patch set 17.1) and an end point (kdb v2.1 2.4.17
common-2, patchset 17.37) and prcs diff -r 17.1 -r 17.37. That single
patch against 2.4.17 is all the outside world needs to see, the only
history is "kdb v2.1 2.4.17 common-2". It does not matter if I
backtracked and discarded some twigs to get to that final end point,
the rest of the world only cares about the end point.
For that model to work (which is effectively what diff/patch does now),
developers need a repository system that can consolidate lots of little
changes into a single patchset. Distribute and replicate the single
patchset, only the original developer retains the individual steps that
made up the combined patchset.
-
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:31 EST