>Not only in use, but you may have multiple new versions in QA testing
>concurrently and you'll want to tag the release straight from its
>testing branch so as not to affect anything else.
True, but I think this is a mindset issue. Whenever I've been asked to
release something to a test server, I've been asked to release changes X,Y &
Z (perhaps because they make up a certain release). If I have more than one
QA server, then they must be QA'ing different features. So, merge those
features together, and release them to test. Admittedly, you dont have a
branch that mimics that server's state, but I'm not sure this is an issue.
I'd rather my branches related to distinct changes, than the state of a
machine (production excluded of course).
> > I guess I made the assumption that the system is only going to be
>running in
> > one place - one production server (or one cluster perhaps). When I've
>been
> > defending the feature-based approach, this is type of system I've had in
> > mind. You can therefore link every tag on the trunk with a point of time
>at
> > which that version of the system was running in production.
>
>A tag isn't exactly 'on' the trunk - it becomes its own entity and has
>its history regardless.
Yes, I know. We tag branches as well as the trunk. I was using this as an
example for the trunk only. But I take your point.
>
> > But, for the systems that I had in mind, which are never going to be
>sold on
> > because they are part of a company's infrastructure, or a website, I
>think
> > the stable-trunk still wins.
>
>I can see an advantage for stable-trunk where you permit public access
>to the repository so everyone doesn't have to know about the purpose
>of each branch. Otherwise the trunk may be more valuable for new
>development work that hasn't reached the QA stage yet.
>
I disagree. I think having a stable trunk, that mimics the production copy
of a system is very important. But, this is one of those core things that we
might never agree on :)
I still don't see any compelling reason to ditch the feature branch approach
for the release branch approach.
As they used to say in uni, please discuss :)
_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 00:43:05 2006