RE: 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).

>>>>>>>>>>>>>>>>>>>>>
        Yep, that's the way I am used to doing it too. If it's a very
small change, then it might not even be necessary to create a branch
(although there's so little overhead with a branch in Subversion, you
might as well).
>>>>>>>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>>>>>>>>>
        We use a very simple one - one that mentions the current release
name,
a brief description of the issue/feature that the branch is for, and the
revision number of the repository at the point it was branched/merged
>>>>>>>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>>>>>>>>>
I think in CVS you might want to, but Subversion branches are so
lightweight, I'd argue for just leaving them there so you can take a
look if you ever need to for whatever reason
>>>>>>>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>>>>>>>>>
I suppose this is the same with any conflict. You ultimately need some
knowledge of the code to be able to make an intelligent decision about
which
side of the conflict you want to keep. Looking through the history of
the file usually give some hints too
>>>>>>>>>>>>>>>>>>>>>>

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.

>>>>>>>>>>>>>>>>>>>>>>
I just lost the debate in our office. I said that ultimately, in a large
system, with lots of releases, and using branches to keep features/bug
fixes
all apart from each other so that you can have maximum flexibility, both
approaches ultimately end up having about the same amount of merging and
branching. In fact, if you draw it out on a piece of paper, they are
almost the same diagram. This somehow seems to have been interpreted as
'release strategy is best', but since I think both are so similar, I
lost the will to argue any more :)

The feature strategy, for me, says "OK, lets suppose this system is
going to have a complicated lifecycle. Lets use a branching strategy
that handles this from the start. (granted, it doesn't support multiple
running versions too well).

The release strategy says "Lets assume this is going to be really
simple. If it get's hard, we'll start branching just like the feature
strategy.

I personally like the idea of a stable trunk, which tracks the state of
the production system.
>>>>>>>>>>>>>>>>>>>>>>

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.

>>>>>>>>>>>>>>>>>>>>>
Probably - although I've not used Maven (or similar) yet, so I can't
really comment
>>>>>>>>>>>>>>>>>>>>>>

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
*** Disclaimer *** 
This electronic communication is confidential and for the exclusive use of the addressee. It may contain private and confidential information. The information, attachments and opinions contained in this E-mail are those of its author only and do not necessarily represent those of London Scottish Bank PLC or any other members of the London Scottish Group. 
If you are not the intended addressee, you are prohibited from any disclosure, distribution or further copying or use of this communication or the information in it or taking any action in reliance on it. If you have received this communication in error please notify the Information Security Manager at ISM@London-Scottish.com as soon as possible and delete the message from all places in your computer where it is stored. 
We utilise virus scanning software but we cannot guarantee the security of electronic communications and you are advised to check any attachments for viruses. We do not accept liability for any loss resulting from any corruption or alteration of data or importation of any virus as a result of receiving this electronic communication. 
Replies to this E-mail may be monitored for operational or business reasons. London Scottish Bank PLC is regulated by the Financial Services Authority.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org