On Tue, Nov 29, 2011 at 2:13 AM, jes Struck <jes_at_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
lesmikesell_at_gmail.com
Received on 2011-11-29 15:12:42 CET