Re: src/sys/vfs

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost