On Friday 08 May 2009, Zach Welch wrote: > Even assuming he used a branch, there is no way for any one person can > test architectural changes in one.
Not so. The testing will be limited ... but that's a good reason to use branches, in whatever SCM is used. > Stuff would be broken in the trunk > after the merge, but -- instead of watching the progress from beginning > to end -- users now effectively receive a single patch series that > absorbs all of the changes into the tree at once. That's the art of partitioning patches so they merge smoothly. The tree should still work after each patch, and each patch should have a clear motivation. I'm used to seeing the patches developed in quilt, going through potentially several iterations, and not merging anywhere public until they're fully cooked. Other folk use alternative schemes (I'm told I should look at stgit). What appears to have been missing here is the "cooking" stages for those patches. > The same series of > problems will hit the tree, just now there are more revisions to bisect > and clean up. After all, most users will not take the chance to work > incrementally with the branch author. And most developers know that. But that's different from not being able to do so -- e.g. patches going right into mainline, without effective list review. "More revisions" is to some extent inherent in a cleanly partitioned patch series. (My own rule of thumb is to avoid patches over 20KB.) Shouldn't be a problem. "To bisect" ... sort of presumes something that supports bisection nicely. GIT anyone? :) _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
