On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote:
Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone).
OK, so let's say our state today is branches/1.1 and we're about to cut 1.1.0. branches/1.1 In order to prepare the release, you copy branches/1.1 to tags/1.1.0 and then (if I understand you right) move branches/1.1 to branches/1.1.1: branches/1.1.1 tags/1.1.0 Now you discover that the tag was bad, but code has been checked in to branches/1.1.1. What do you do? I don't think this has any advantage over leaving branches/1.1 and copying it to tags/1.1.0: branches/1.1 tags/1.1.0 Either way, if the build is bad, you'll have to copy tags/1.1 to somewhere else to work on it (branches/1.1.0??) until you're ready to cut another build. It might be better to just suck it up and cut branches/1.1.0 at the time of the freeze, and then tags/1.1.0 from that when you want to create a candidate: branches/1.1 (now 1.1.1-SNAPSHOT) branches/1.1.0 (frozen, copied from branches/1.1 at freeze time, only super-critical changes) tags/1.1.0 (candidate release, copy from branches/1.1.0) Then if the tag is bad, whack it, fix up branches/1.1.0, and recopy tags/1.1.0 Thanks, Aaron
Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. > plus it wouldn't require everyone to do a full checkout > of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
