richard
wouldn't this be more a problem of application design? To personalize
this changes dinamically and ve put then in place dinamically thought
configuration?
Emerson
On 09/11/06, Richard Gundersen <richardgundersen@hotmail.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 12:46:21 2006