> 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
