Re: Shared branch vs single branch
On 23.09.2013 19:44, C M wrote: What are some of the pros/cons of using a single/shared branch versus the private developer branch? We are having an internal debate within the team where the idea of a single/shared branch was proposed in reaction to two specific issues: 1. In the merge to trunk from individual developer branches, some code was lost. It remains unclear whether it was user error on part of the person doing the merge or the tool which caused the problem. In at least one case, a file was partially merged. 2. The combined functionality (features assigned to two different developers) was not included in the final application build and delivery. In this case, the assignments were made months apart and one feature was delivered without the other. The expectation is that a shared/single branch will correct these issues. I am curious to know what advice others can offer and what (if any) potential issues we may experience with the new paradigm. Changing the way you do branching will not solve your problems, since the they're by tool but by lack of communication within the team, and non-existent product management. User error will always happen, but Subversion will not magically warn you about it. You need other quality assurance procedures in place for that. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Shared branch vs single branch
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. A general rule can't cover all cases, but in general I think the longer you let branches diverge with isolated work, the more likely they are to have conflicting changes that will take extra work to resolve when you finally do merge. -- Les Mikesell lesmikes...@gmail.com
RE: Shared branch vs single branch
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? BOb A general rule can't cover all cases, but in general I think the longer you let branches diverge with isolated work, the more likely they are to have conflicting changes that will take extra work to resolve when you finally do merge. -- Les Mikesell lesmikes...@gmail.com
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 placeYes, people have to set things up, but there are tools that can help. -- Les Mikesell lesmikes...@gmail.com
Re: Shared branch vs single branch
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 placeYes, people have to set things up, but there are tools that can help. -- Les Mikesell lesmikes...@gmail.com
Re: Shared branch vs single branch
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
RE: Shared branch vs single branch
What are some of the pros/cons of using a single/shared branch versus the private developer branch? We are having an internal debate within the team where the idea of a single/shared branch was proposed in reaction to two specific issues: 1. In the merge to trunk from individual developer branches, some code was lost. It remains unclear whether it was user error on part of the person doing the merge or the tool which caused the problem. In at least one case, a file was partially merged. It was the user that did the merge. It will only commit what you tell it to commit. This is a people problem, not a branch strategy issue. 2. The combined functionality (features assigned to two different developers) was not included in the final application build and delivery. In this case, the assignments were made months apart and one feature was delivered without the other. Once again, a people problem. The expectation is that a shared/single branch will correct these issues. I am curious to know what advice others can offer and what (if any) potential issues we may experience with the new paradigm. Thanks. Amad. 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. BOb
Re: Shared branch vs single branch
On 9/23/13 1:15 PM, BRM wrote: 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. In my experience, working in a dirty trunk typically results in less checkins by developers. I don't consider this a good thing as their changes tend to remain uncommitted for very large periods of time (in the order of a week or so).
RE: Shared branch vs single branch
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
