On 12/11/06, Talden <talden@gmail.com> wrote:
> 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).
In this case (bug fix), i think you could use the developer workspace
for the change.
> What recommendations do people have for commit messages needed to
> track the branching and merging points?
We use the revision number when the branch was taken
> Do most people clean up these kinds of branches like this?
I crated a cemetery folder inside branches, which where I move the old
branches. In this way they are easy to find and don't confuse people,
leaving only the branches in use directly inside branches directoty.
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 13 16:18:19 2006