On 9/23/13 1:04 PM, C M wrote: > 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".
In my opinion there isn't a single answer to this question. Which strategy you want to use is entirely situational. If you're using a single shared trunk then you're going to run into situations where you'll want to still use a branch because the work being done is disruptive. The only alternative to that is to start adding flags in your build system to hide this. If you use branches often, then you'll still have changes where they are small enough there's no need for the branch. > 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. In truth every commit is a merge (the HTTP method SVN uses for commit is MERGE). Who better to be committing/merging than your developers? Consider the following situation. Developer A and B are both working on a project we'll call widgets. The code has the following layout. widgets widget/foo.c widget/bar.c widget/baz.c main.c Developer A starts modifying a function we'll call stamp(), let's pretend that stamp controls the formatting of a date and serial number coding on the widgets we're producing and lives in main.c. foo and bar widgets have this coding but the baz widget is new and hasn't had it added yet. Developer A has been given the task of adding a time code to the stamp. Developer A has an entire working copy at revision 20. Developer B is working on the baz widget and is now getting to the point of adding the stamp and adds a call to stamp() to baz.c. He commits revision 21 doing so. Developer A continues working against revision 20 has finished adding time to stamp() and in the process adding a new argument to input the time to stamp. He updated the calls in foo.c and bar.c but since he only has r20 he doesn't see that widget/baz.c has added such a call. He commits his code in r22. Now the baz widget has been broken. Subversion didn't complain because the changes were in different files and don't appear to conflict. Now consider if both developers had been working on branches. If they merge their branches back to trunk in the same order then you'll have the same problem. All branches do is delay the conflict and potentially limit the number of people that are impacted by the conflict. In my opinion the further you get from the creation of the conflict both in time and individuals the harder it is going to be to fix it. But that also doesn't mean you should never use branches. I really don't understand how CM doing merges helps avoid problems. The developers are in the best position to understand the impacts of their merges and deal with any conflicts (raised by Subversion or semantic and not shown as a conflict by Subversion). If you're uncomfortable with your developers knowledge of Subversion, you should invest in them and spend the time improving that knowledge. It'll pay off more than any change in branch strategies ever can, since as I demonstrated above, both strategies can have the identical problem.