If by "single/shared" branch you mean everyone working out of the same place...then yes - you'll trip over each other from time to time.
I've worked in both "trunk is prestine" (all work in branches) and "trunk is dirty" (all work in trunk) models; when you have multiple people the "trunk is prestine" works a lot better, but as others have noted people doing the merges have to ensure they are done right - and that includes testing. "Trunk is dirty" won't save you from bad merges, it'll just make more conflicts in your working copy as you do updates - something that drove a colleague of mine nuts so I started working in my own branch for that project. You also have to more frequently be doing "svn update" on your working copy to minimize impacts of what others are doing. $0.02 Ben ________________________________ From: C M <cmanalys...@gmail.com> To: Les Mikesell <lesmikes...@gmail.com> Cc: Bob Archer <bob.arc...@amsi.com>; Subversion <users@subversion.apache.org> Sent: Monday, September 23, 2013 4:04 PM 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". 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. On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell <lesmikes...@gmail.com> wrote: On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer <bob.arc...@amsi.com> wrote: >>> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <bob.arc...@amsi.com> wrote: >>> >> It really depends. I think all work for a specific release should be >>> >> done in a >>> single branch/folder. Many people follow the stable trunk model. In this >>> model >>> you generally do all work on trunk and then branch for a release. This is >>> the >>> same model svn itself is developed under. In this model you would also use >>> what are called "feature" branches. This is generally for a feature/use >>> case that >>> will take more than a day to complete or will be worked on by more than one >>> developer. >>> > >>> > Once again, it's up to the people not the tool to ensure your release >>> management is done properly. >>> >>> Well, sort-of. It is always a good idea to (a) include tests for new >>> code and (b) have a workflow that ensures that the tests are run and >>> that someone checks the results. Expecting one person to never make >>> a mistake just doesn't always work out. >> >> Isn't is up to the people to put those processes in place? To create the >> correct workflow? To write the automation? >> >> I don't think I ever said it should be ONE person's responsibility to >> manually do this work. Where did I say that? > >You didn't explicitly say it was one person's fault, but what you said >could easily be interpreted that way by anyone who had to ask the >question in the first place.... Yes, people have to set things up, >but there are tools that can help. > >-- > Les Mikesell > lesmikes...@gmail.com >
