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.
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.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 14 | next ›
Discussion Overview
groupusers @
postedSep 23, '13 at 5:45p
activeSep 24, '13 at 12:14a



site design / logo © 2021 Grokbase