Glad you are enjoying it :)
I like a good debate and I might be proven wrong. I'm applying my previous
experience to a new company where we don't have a strategy yet.
In my last job, the systems I looked after were used in 20+ countries. So,
one copy of the system, with lots of customisations. Each country would have
their own changes. Sometimes they would be cosmetic and low risk. Other
times, they would say 'Spain has a new law regarding X. The system must
support this law on 1st August 2007'. The application change cannot however
be released before then. It must be released at midnight, 31 July 2007,
otherwise the system is operating illegally.
At the same time, Germany has another change. Theirs will take a long time
to implement so development must also be started now. But theirs must not be
released until 1st October 2007.
If all development is done on one trunk branch, then at some point I have to
tell Germany that because Spain MUST have their change, I have to release
their change too. I know what will happen - Germany will stop using the
system.
Using feature branches, when it comes to 31 July 2007, I just merge their
change into the trunk and release it. (OK, this would be done maybe a week
or two in advance for testing purposes). Germany isn't affected. Everyone is
happy.
>From: Ryan Schmidt <subversion-2006d@ryandesign.com>
>To: "Gundersen, Richard" <Richard.Gundersen@london-scottish.com>
>CC: <users@subversion.tigris.org>
>Subject: Re: Branching strategy - Feature vs Release
>Date: Wed, 8 Nov 2006 17:41:19 -0600
>
>
>On Nov 8, 2006, at 10:12, Gundersen, Richard wrote:
>
>>I haven’t had anywhere near the number of replies I was expecting saying
>>my approach is awful.
>>
>>Perhaps this is because it’s something that’s been debated to death
>>before and nobody wants to get it started again. Or perhaps it’s because
>>it really is better than the release-based branching strategy (trying to
>>stir up some controversy here :) )
>>
>>Does anyone know of any real advantages the release-based approach has
>>over the feature-based way?
>
>I never imagined that these were conflicting strategies; I think they can
>and in many cases should coexist harmoniously. I'm just enjoying reading
>your arguments and the responses in this discussion; I don't have too much
>to add to it.
>
>In the company where I worked, we primarily used release branches; most
>changes to be made were small enough that they could be done in one or two
>commits, and thereby not destabilize the trunk. However, we did allow
>larger development to occur on trunk, even leaving it unstable, while
>releases could still be cut from the latest stable release branch. One of
>our developers liked the feature-branch idea and used it on some
>occasions, but the rest of us didn't bother to learn or practice that.
>
>I'm not at all convinced that the way we used Subversion was the best way,
>so I'm certainly interested in reading the arguments in this thread.
>
>
>>Anyone know how are Subversion releases themselves done?
>
>Looking at the branches directory of the Subversion repository, I think
>it's safe to say that they make use of both strategies:
>
>http://svn.collab.net/repos/svn/branches/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
_________________________________________________________________
The new Windows Live Toolbar helps you guard against viruses
http://toolbar.live.com/?mkt=en-gb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 01:01:47 2006