Re: Branching suggestions needed...

[Dennis Jones]

"James Depaul" <address@hidden> wrote in message
news:address@hidden

> improve that process. Here's the proposed flow:
>
> Every Wednesday we have scheduled delivery date. I'm thinking that just
> prior to the final build create a /Branch - I'm thinking of it as a 
> special
> TAG that marks the completion of that development cycle. Do the build 
> using
> that /Branch, and deploy it accross the infrastructure (DEV, QUAL, PROD,
> respectively).
>
> From that point forward, any code fixes should be done to the /Branch 
> code.
> Any NEW development should continue on the /main trunk (and hopefully 
> there
> won't be many mistakes - that I'm sure would complicate this for us).

That is not only reasonable, but a very good (and common) strategy.


> Thus we'd have an early branch each time we build/deploy and any fixes to
> that code base would be performed on that /Branch, while new development
> would continue in parallel on /trunk.

Right, which is one of the primary reasons for (and advantages to) 
branching.


> What I'm not sure about is: if we do
> have fixes when do we need to merge them into the /main trunk code?

The sooner the better.  Frequent merges reduce that chance of conflict.  The 
longer you wait, the greater the chance that a merge will result in a 
conflict because there is more time for someone to discover the same bug on 
the trunk and make a similar --but not exact same-- change on the trunk.


> What
> happens if we gave fixes on the /Branch, we merge them into the /trunk and
> we have OTHER fixes to make to the prior release?

Not sure what you are asking here.  If by "prior release" you mean another 
branch that occured before "/Branch", then you just make your changes to 
that branch, then merge them into the trunk the same way you do the ones 
from "/Branch".  Am I missing something here?

- Dennis