Rick Hillegas wrote:
> Thanks to everyone for thinking through the issues here. This has been
> very helpful. I don't understand the practical advantages of a copy
> versus a branch, particularly since I will have to create a branch
> eventually. I could use some more education here. What would be the
> objections to the following scheme? A big advantage to this scheme is
> that it's something I can wrap my mind around:
>
> 1) I create a 10.2 branch.
>
> 2) I turn on the beta bit in that branch.
>
> 3) I generate the beta candidate from that branch.
>
> 4) In the meantime, bug fixes accumulate in the trunk.
>
> 5) At some point I mega-merge the trunk into the 10.2 branch based on a
> triggering event:
>
> a) triggered by the need to generate a new release candidate
>
> b) triggered by the checkin of destabilizing work such as a partial
> feature
>
> 6) After the mega-merge, fixes must be applied to both the trunk and the
> 10.2 branch.
>
> Thanks again for helping me work through these issues.
I think the point to the beta branch and a real 10.2 branch later is:
1) branches (copies) are cheap in svn, so no major cost there.
2) There is no "mega-merge" required.
3) history is cleaer, easy to see 10.2 branch created from trunk @
503134. The mechanism you propose has the history being:
10.2branch created from trunk @ 489243 (made up numbers btw)
Big merge of stuff from trunk between 489244-503134
(was this done right?, was a file missed?, all possibilities).
Dan.
