On Tue, Nov 29, 2011 at 2:13 AM, jes Struck <j...@praqma.net> wrote: > Thank you for all youre responses > > The point uis that im not interested in feature branching, my developers > are interested in working with developer branches because its hard for them > to setup up eclipse each time they branch of from trunk, (i now the switch > command is the solution) , but atm. they are just not branching, so to get > them started we will work like they get developer branches and the hope the > discover how easy it is and start using branching for features. which i > agree is the right thing onles youre in ClearCase UCM. > > A branch is a branch. There should be absolutely no difference between copying a new branch from the trunk after completing a feature and switching to it, deleting the head of the current branch and copying back to the same name from the trunk, or properly merging the other trunk changes into the branch. Well there is a difference but only in the way you would access old versions of the branch work to find temporary changes that didn't get merged to the trunk. With different branch names (the feature branch approach) you'd go to the branch name containing it. If you delete and recreate the same branch name you need peg revision syntax to go back, which may be harder to remember. But the point is that you have to get the other changes from the trunk into the developer branch one way or another and going in the forward direction they all look the same. Personally I think the 'dirty trunk', 'release branch' approach makes more sense if your development work is fairly close-coupled and everyone wants quick access to each others work when big changes are in progress but it may be hard to think that way if you are used to a system that doesn't resolve conflicts easily.
-- Les Mikesell lesmikes...@gmail.com