Re: Branching strategy - Feature vs Release

Am I right that in the feature-based approach the sequence for a
bug-fix would be something like

1. IssueX from tracker is assigned to developer
2. developer makes fix branch .../branches/bugs/issueX and switches to branch
3. Makes modifications and test fix (committing as appropriate)
4. switches to head and merge from branch, test and commit
5. delete branch (assuming such cleanup is preferred).

What recommendations do people have for commit messages needed to
track the branching and merging points?

Do most people clean up these kinds of branches like this?

I assume a 'features/featureY' branch follows much the same progression.

If you get true conflicts in the merge stage what steps would you use
to find the cause of the collision? (I'm guessing this is where
recording revision numbers in branch and merge commit messages is
crucial - which numbers?).

We use a hybrid of feature and release in CVS purely because the
branching is so painfully slow. If these steps and the svn commands
that support them are truly simple then I hope to convince our team
that the feature model should be used instead.

Moving to the feature-based branching model should make introducing an
automated nightly build/test on trunk more practical too as the log of
commits to trunk would be quite concise and clear (assuming commit log
conventions are followed) as to who committed and from which feature
or bug the problem arose.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org