> merge conflicts are preferable to changes that overwrite other changes
Nobody is saying that. The difference is really merging as you go vs doing one big merge at the end. I personally fall on the side that it's far easier to merge as you go.
Master is typically periodically pulled into the feature branch to ensure you're working against the most current version of the codebase.
EDIT: Yes, this can create an ugly revision history, but that's what rebasing is for, right?
Pros or cons of each aside, advocates of feature branch based development should recognize that they are merging less often than they would if they were doing trunk based development.
It sounds crazy now that I write it down, but it really keeps our commits clean.
Checking in code to the VCS that makes the tree NOT build will get you screamed at (at least within the OpenBSD project). This requires proper planning for big changes, and to break them down into small, easy to review, patches.
OpenBSD uses CVS as main repo because it fits their development style. Bevore you knock down CVS look at AnonCVS and cvsync. http://www.openbsd.org/papers/asiabsdcon2009-release_enginee...
In order for this workflow to be reasonable for any development team of a size greater than about 3, each commit would need to move all the code in to a working state. While a reasonable pattern in theory (Don't TRY commit breaking changes!), it is frequently useful to track code in an intermediate state. Sometimes (read frequently), this code may not be representative of the final state of the technology or may not even work as it should. Not maintaining individual branches means that these changes are exposed to the entire team and can be very very messy.
All in all, what a silly approach to revision control. Take advantage of the latest patterns and a system that provides the loosest coupling and highest distribution. If we do as the author advocates, we might as well all just switch back to CVS...