Software Branching and Parallel Universes

#102

Regressions are definitely one of the biggest risks when merging. Your customers will not appreciate that.

Personally I don’t see what’s wrong with tagging releases in SVN. I understand that it’s a bit like using a sledgehammer to pound a thumbtack into your cork board, but it does the job just fine. And who knows, you might actually want to merge it someday if you discover some crippling bug that affects the 12 most recent versions and a bunch of users are still using the old one. If the tag is technically a branch, then it will save you a lot of last-minute scrambling.

Maybe some SCMs think of tagging as just slapping a label on a particular item in the history. That’s fine too, but to me it’s only a superficial difference. I think it’s an OCD-like impulse, getting upset that there’s some awful dangling branch that will probably never be merged. Who cares - I know what it’s for, that’s why it’s in a “tags” directory.

#103

I used the third dimension analogy in Practical Development Environments (O’Reilly, 2005). One useful point is that movement in the branching dimension is easy one way but always harder the other way (merging). Whether your tool is centralized or distributed, merging involves resolving conflicts which will alway take some human effort. Different tools just make that effort a bit easier.

Another analogy I use these days with clients is comparing the three dimensions to a building with each release’s files on a different floor. It’s easy to walk downstairs with a copy of a file for the people there, but walking upstairs with a file is always against gravity.

People who think that merging will ever be fully automated probably also think that anti-gravity suits are just around the corner.

#104

Sorry guys, but to suggest that merges are avoided due to “fear” is terribly ignorant. There is a ridiculous amount of data and case studies done on this to show how much trouble merges can create.

This is not fear: it’s well-founded caution.

If you want to attack trunk-based development attack TBD with some sensible arguments beyond mind-reading. To simply criticize/portray TBD practitioners as developers who are afraid to branch is ridiculously short-sighted and inaccurate. Caution due to a history of merge conflicts and schedule over-runs is not fear, its just good judgement to be cautious.

There are many wildly successful software companies such as google, amazon, and facebook who use Trunk Based Development. They do not do this from fear. lol

Please, find a cogent and thoughtful argument to refute TBD.