On 11/8/2006 5:06 AM, Gundersen, Richard wrote:
> Hi All
>
>
>
> We're having a big debate where I work over whether or not to use the
> "release" based branching strategy, or the "feature" based way.
>
>
>
> I've always worked with the latter. These are the reasons why:
>
>
>
> 1) Trunk is always stable. This always mimics exactly what's in
> production.
>
> 2) I do all new work on a branch (whether it's a small
> experimental change or a new release which is essentially a collection
> of new features). This to me has the following additional advantages
>
> a. My new changes don't affect the production codebase
>
> b. When the customer who requested change X wants it to go live, I
> can merge it in to the trunk (because its own isolated branch), and
> release only that change (plus whatever was in trunk originally). I then
> commit it, tag it, and hey presto, trunk still mimics production
> exactly. With the release based approach, with everyone committing
> different changes to the trunk, when a customer wants change X to go
> live, I have to tell him that it can go live, but I have to tell another
> customer that because I have to release X, his change Y must also go
> live too. This situation might never occur with systems that have a
> simple release lifecycle, but when you're dealing with large systems
> with different sets of customers (especially if they have different
> legal requirements, or they are in different countries) I think this is
> really important.
>
>
>
> The arguments against this approach are often:
>
>
>
> 1) Merging is hard. I don't like it
>
> a. Well, in my experience with Subversion and CVS, merging is
> actually quite easy. I might have a few conflicts to resolve every now
> and again, but they are usually pretty easy to iron out, especially if I
> keep my branch up to date with the trunk (which might have had some bug
> fixes done to it over time)
>
> 2) Keeping track of lots of branches is hard.
>
> a. Not really. If I use a good naming convention, a handful of
> branches are easy enough to keep track of. It's not as if I'm going to
> have hundreds of branches to worry about, in reality
>
> 3) We have release branches so you know exactly whats on a
> production server
>
> a. So does this approach - whatever is on the trunk is in
> production. And, a release branch by definition changes over time (until
> it's tagged as final after which there will still be an element of
> merging involved to get it in sync with the development branch (trunk in
> this case)).
>
>
>
> I can see why people would favour the release branch strategy, because
> it 'sounds' much simpler, but I think the benefits of the feature based
> approach far outweigh the negatives. I expect a lot of people to
> disagree with me, but it's a good debate and I'd welcome any comments.
One other argument in favour of doing development on the trunk and
release from branches: If you look at the log for a file, you see the
history of changes, not a series of "lots of changes merged from foo
branch" messages.
Duncan Murdoch
>
>
>
> Thanks
>
>
>
> Richard
>
>
>
>
>
>
> *** 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
Received on Wed Nov 8 13:00:34 2006