"James Depaul" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> 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
