> From: C M [mailto:cmanalys...@gmail.com] > Sent: Monday, September 23, 2013 4:05 PM > To: Les Mikesell > Cc: Bob Archer; Subversion > Subject: Re: Shared branch vs single branch > > Unfortunately, we are lacking on processes and there's a definite lack of > product management. > But coming back to my original question: Are there any potential gotchas > with using a single/shared branch? For now, that's the only change the team > (and leadership) is looking to as the "solution".
Firstly, one branch only works if you only ever have one and only one development steam going at a time. This "never" happens because at a minimum, you need a branch to support production fixes, a branch for QA fixes for the "final" release candidate, and a branch for the next release, e.g.: * /branches/1.0.1 - prod bug fixes for 1.0.0 in prod * /branchs/1.1.0 - 1.1.0 is in its final round of QA testing, so only 1.1.0 bug fix work is accepted * /branches/trunk (aka 2.0 work) In other words, don't ignore, gloss over, or otherwise lie to yourselves over the need to support multiple branches and merging. Secondly, everyone will still require training. Multiple branches (see Firstly above) will require training for everyone. Even if you have the CM guy do the merges, you still need to teach the developers how to avoid creating Evil Twins (i.e. a particular Tree Conflict.) An Evil Twin is created when you 'svn add foo.java' on both the trunk and on the branch, instead of merging 'foo.java' from trunk to the branch. Thirdly, you need process and project management. If you can't track your work, even "single" branching is going to fail hard, such as when you have to back a feature out of trunk due to time constraints. If you can't identify/track the work back to individual check-ins, then you will have great difficulty in reverse merging a feature out of trunk and merging it to its own branch. If you can't assign work and/or manage requirements, then, technically, you cannot, in good faith, decide whether single or multiple branches are right for you. Fourthly, Semper Gumby; "Always Flexible." Branching gives you flexibility. Going with single branching limits your ability to change, adapt to, or manage releases. If you have lousy requirements management, then single branching means you're more likely to wind up in death marches, late nights, and relying on full regression testing (which takes time that you won't have) to verify that you all haven't broken something stupid on trunk. If I had lousy/incomplete/late requirements then I would want to use feature branches to help mitigate the pain. Fifthly, keep your resume up to date. A good marriage counselor helps as well. Keep in contact with your company recruiter in case you experience higher than average developer burn out. Over-dramatic, but no process == inefficient work == making up the time with people's personal time, i.e. late hours, weekend work, etc.. To actually answer your question, the pitfalls of single branching are: a) people working on the same files will create conflicts during 'svn update'. However, svn locking can help reduce the pain. Dividing up the work so that folks are working on different parts of the software helps as well. Communication is key when multiple developers touch the same set of files. b) having to remove code. If a feature is unstable or cannot be completed in time, then you will need to reverse merge it out. Which can be more difficult with single branching over feature branching. Difficultly is increased the longer/bigger the release is, due to the increased chance of interdependencies with the removed feature. However, if you're doing Agile development (short release cycles/sprints, a small set of well defined requirements for each sprint, etc.) then the dirty trunk approach should work mostly easily. However, the longer your release cycle, the greater your chances of having to rip out a feature and the greater the difficulty it will be in doing so (due to dependencies, larger set of QA test to run through, etc..) > Our developers code on a Unix like platform and have little SVN experience to > boot. The idea of turning over merging to them seems to be a recipe for > disaster. I would prefer to let the CM team handle the merges and figure out > what I did incorrectly to mess up the previous merges. Go with the trained CM guy. Tree conflicts in Subversion aren't exactly well documented and require some experience to do correctly. However, your CM guy can't merge based on business logic, e.g. if something *shouldn't* be merged (such as a temporary hack) then you Someone(tm) needs to work with the Merge Meister, i.e. have a merge party. Good luck. It doesn't have to be perfect, but the more up front planning you do, the less of your life you lose to stress. Also, defining a process is the first step towards process improvement and a saner career. =) /soapbox off
