On Wed, Jul 29, 2009 at 5:11 PM, Uwe Schindler<u...@thetaphi.de> wrote: >> > My suggestion was to write the build script in a way that it checks out >> the >> > branch with the same revision number as the current base dir (trunk). >> >> I think this would work, as long as we always commit top-level and >> back-compat tag in one transaction (commit)? >> >> (And, even if we don't do it as one commit, the risk that someone >> happens to do a checkout between the two commits is presumably >> negligible). > > I think if you first commit in backwards-branch and then in trunk, you never > get an inconsistent state. The trunk revision is lower than the new branch > revision, so nothing changes, as a trunk checkout and test-tag would run the > tests from its current revision (that did not change).
I don't think that's right? Ie, if you first commit on the back compat branch, but before you commit to trunk, somebody else does a checkout of trunk and tries to run "ant test-tag", they will see "false" failures? (Because that trunk checkout will be a revision that includes the back-compat changes you just committed but none of the correspondingly required trunk changes). I wonder: if we run an "svn commit . tags/lucene_2_4.../src" whether svn will do this as a single transaction? Because "." (the trunk checkout) and tags/lucene_2_4... are two separate svn checkouts. (I haven't tested). If it does, then I think this approach is cleanest? > This is the same as now. You can modify the bw-branch and create a new tag, > but as trunks common-build is not updated, nobody would see it. > > You only get an inconsistent state if you have run test-tag before and have > a current checkout of the bw-branch. If you then do svn update on the > bw-branch you will update this to last revision. But if you do this, you > will also update trunk (otherwise it would not make sense). > > There is only one problem: If you already have checked out the branch with a > specific revision and then update trunk, the next test-run will use the old > tests (as dir already exists, currently it would checkout a new tag because > dir name changed). Because of this, test-tag should also do a svn update to > the current trunk's revision. test-tag already does the "download-tag" which should prevent this? >> > Alternatively instead of putting a tag name into common-build.xml, it >> could >> > be the revision number. So it would check out ./branches/ >> > lucene_2_4_back_compat_tests with the revision given in common-build. >> >> This would also be better than what we have today (saves the extra >> "svn copy" step), but if we can make the first approach work that's >> even better! > > I suggest two variables in common-build.xml: > - backwards-branch or backwards-branch-url (must be changed when 3.0 is out > and 3.1 starts in trunk). > - backwards-revision > > The same problem with trunk updated and branch still available also happens > here. So each run of test-tag should do a svn update to the revision from > the config before (maybe give the possibility to switch this off or only > update, never downgrade) We don't have the problem today because the "download-tag" step sees the new revision (now a named tag) in common-build.xml, and does the update before running test-tag. Mike > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
