This is the procedure I was expecting (except expected to have to
merge myself it i wanted something in branch), sounds good to me.
I was going to be ok with holding up the branch for the code
rototil if necessary, that seemed like a reasonable delay for
solving an apache mandate. Having
a real branch I think also makes it easier if for some reason I
need to fix a specific bug that shows up in the beta and for some
reason I don't wank to work in the trunk.
I don't understand the workings of svn, if at step 5 you decide
everything that is in the trunk at that point really wants to be
in the branch (and nothing has independently gone into the branch),
is it easier to make a new branch than to mega merge?
I think it is not a good precedent to count on people letting you
know ahead what they might be putting into trunk.
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.
Regards,
-Rick
