Appleton, Will wrote:
>> -----Original Message-----
>> From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>> Sent: Thursday, April 19, 2007 5:27 PM
>> To: Daniell, Casey B; email@example.com
>> Subject: RE: RE: RE: Release Branches / 3-plus Development Streams
>> I don't understand a couple of things about branch/merge scheme. If
>> releases are developmented on branches, what is the trunk really being
>> used for? Secondly, what do you mean that you keep the trunk pristine?
>> By pristine I might think you mean "unchanged" but that can't be right
>> since you are merging changes to the trunk
> Here's a nice article (treatise really) that has lots of branching
> strategies. Nice clear explanations of various branching patterns and
> why/when to use them.
> Not really an answer to your question exactly, but it's nice background
> on branching/merging in general.
I think the first thing you need to decide is whether you care if the
trunk/HEAD is always a released revision or not. For some places,
especially ones that permit public or uncontrolled access, this may be
important. If it isn't, it can make it easier to track history if you
always develop on the trunk and only branch for releases that need their
own separate maintenance and for changes that might be disruptive if not
isolated from other concurrent work on the trunk. You might not even
need to create the release branches until the first support changes are
needed. Just copy any revision you want to be able to reproduce to a
tag, then when you need to make a change that doesn't affect anything
else, copy the tag to a branch to do the work. I'm not sure you can
generalize about what happens after this - sometimes the fix you need
will already exist on the trunk and you can merge it, sometimes it will
be something you don't need anywhere else.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 20 17:57:36 2007