begin quoting David Brown as of Wed, Dec 19, 2007 at 12:15:41PM -0800: > On Wed, Dec 19, 2007 at 11:07:04AM -0800, MattyJ wrote: > > >Philosophically, that seems fine to me. I'd rather check my own crummy > >ideas in separately from my reviewers so it's clear in the history that a > >review took place, and changes occurred because of them. I check my work > >in frequently, all day long. I'd rather not hold a file open for a few > >days until someone else looks at it. But I'm overly paranoid about that > >kinda thing. > > I think this is a great thing. But, you should be doing that on a branch > so that the other developers don't grind to a halt when your little > checkins break the tip.
That's just a result of not testing before commit. > My experience with perforce (or CVS) is that makes branches difficult > enough that most people don't use them, and either don't check in very > often, or the tip spends most of its time broken. My experience with CVS, P4, and CC branches is that they sound great for 'private development' in theory, but they aren't so great in practice. With CVS, it was that private branches diverged from the trunk too far before merging back in. It was generally better to force all development in the trunk, and to have a rule that The Tree Must Compile At All Times*. This kept the changes small, and easily managed. With P4, I had a different set of developers, who liked to rearrange things. However, they did not use P4's ability to track renames, they just manually copied the file to a new name, deleted the old file (on occassion, without removing it from the repository), and then made their changes. When the time came to merge their little branch back in, it was just as much of a headache as CVS had ever been. But the three-way merge tool *was* nice. With CC, the CC guru made it a point that *all* development would take place in a private branch. And, indeed, it was pretty easy to do so. And because of three-way merging and a nice graphical display of the branches, it wasn't _too_ bad, except that we had a ton of duplicated code. Merge events for small bits of code took as long as merge events for large amounts of code in CVS. Unless you have 'ownership of code' -- where one developer has sole responsibility for changes to a set of files -- private branches just don't seem that beneficial. Better to keep the code *always* compiling (and with unit tests, always running, correctly). [*] Or Else You Bought Lunch For The Team. The team eventually got large enough to where that changed to "Or Else You Bring In The Bagels". > Very lightweight and private branches to me are the biggest win of the > distributed type of systems (git, mercurial, darcs, monotone, etc). I like > being able to hack up things on my own branch until it looks like what I > want to push out. ...without losing your change history, yes. I'm using hg and CVS to do that at the moment. Using hg started out as an experiment in using a sneakernet, via flash-drive. The huge win for HG was the ability to use an MSDOS formatted flash drive for a repository, instead of having to tar up a CVS local working directory or reformat the flash drive to a case-sensitive filesystem. > Another way to think of it: CVS, SVN or perforce lets the developer work on > a set of changes to files that they can then push out as a group. The > distributed ones just extend this a bit further in that the developer can > work on a list of changes that get pushed as a group. It probably depends on your workflow and conventions. -- Some folks like to tie commits to change-request and bug-fix task completions. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
