On Mon, Jul 16, 2012 at 07:52:16AM +0100, David Laight wrote: > Doing development on a branch create its own problems. > > If the branch is long lived (or enyonw else is likely to change > any of the affected files) then is is a continual merge problem. > > When the branch is finally merged the sequence of changes disappears > from the main cvs changes sequence (yes, I know you can go and look > at the branch changes, but they tend to be out of sequence). > > If changes are incrememntal (which this one probably is), then there > is no real problem applying each change to cvs separately - the system > should still build after each. > > This is what dh did with the namei changes - a whole series of commits. > (Probably a lot more work because he managed to commit multiple changes > to the same files quite clode together.)
What rmind doesn't like is when I create a local branch and then empty it into HEAD with a 20-part (or 60-part) patchbomb. I agree this is problematic, but when it's a choice between that or commit the whole thing in one go, I generally think it's better to retain the change history so it can be bisected later if need be, and also retain the individual change descriptions for future reference. I suppose in an ideal world one could create a CVS branch, commit the 60-part patchbomb onto it, and then merge it back to HEAD. It's not clear to me that this offers any significant advantages over just committing. Better is to commit no more than half a dozen patches at a time, of course. But given that a single atf test run takes several hours, this falls down if there's any kind of deadline. (The quota stuff had two extra considerations: one was that it had a tight deadline; the other was that in theory nearly every one of the kernel-level commits should have been accompanied by a version bump, so it was desirable to do them all at once.) -- David A. Holland dholl...@netbsd.org
