Re: backwards compat tests
: 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? you can't have an atomic commit across independent checkouts -- the common root dir needs to be a valid svn working copy. but you can have a common root dir that is a valid svn working copy (without checking out the entire svn hierarchy) by using non-recursive checkouts (-N). you don't even need the full subdir hierarchy, just checkout and descendent directory into that initial working directory hoss...@coaster:~/svn-test$ svn ls https://my.work.svn/svn-demo/ branches/ tags/ trunk/ hoss...@coaster:~/svn-test$ svn co -N https://my.work.svn/svn-demo/ demo Checked out revision 332746. hoss...@coaster:~/svn-test$ cd demo hoss...@coaster:~/svn-test/demo$ svn co https://my.work.svn/svn-demo/trunk/a-direcory/ trunk-a Atrunk-a/one_line_file.txt Checked out revision 332746. hoss...@coaster:~/svn-test/demo$ svn co https://my.work.svn/svn-demo/branches/BRANCH_DEMO_3/a-direcory branch-a Abranch-a/one_line_file.txt Checked out revision 332746. hoss...@coaster:~/svn-test/demo$ svn status ? trunk-a ? branch-a hoss...@coaster:~/svn-test/demo$ svn status trunk-a branch-a/ hoss...@coaster:~/svn-test/demo$ echo foo >> trunk-a/one_line_file.txt hoss...@coaster:~/svn-test/demo$ echo bar >> branch-a/one_line_file.txt hoss...@coaster:~/svn-test/demo$ svn commit -m "cross checkout commit" trunk-a branch-a Sendingbranch-a/one_line_file.txt Sendingtrunk-a/one_line_file.txt Transmitting file data .. Committed revision 332747. -Hoss - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: backwards compat tests
On Wed, Jul 29, 2009 at 5:11 PM, Uwe Schindler 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
RE: backwards compat tests
> > 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). 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. > > 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) - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: backwards compat tests
On Wed, Jul 29, 2009 at 4:31 PM, Uwe Schindler 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). > 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! Mike - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: backwards compat tests
Thanks for the hint, Shai! It is related, but the reason behind the tags was clear to me. 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). 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. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de> http://www.thetaphi.de eMail: u...@thetaphi.de _ From: Shai Erera [mailto:ser...@gmail.com] Sent: Wednesday, July 29, 2009 9:22 PM To: java-dev@lucene.apache.org Subject: Re: backwards compat tests Uwe - I asked this question a while ago on LUCENE-1529 and this is an answer Mike gave: http://issues.apache.org/jira/browse/LUCENE-1529?focusedCommentId=12699177 <http://issues.apache.org/jira/browse/LUCENE-1529?focusedCommentId=12699177&; page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#acti on_12699177> &page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#act ion_12699177 I think it's related to what you ask Shai On Wed, Jul 29, 2009 at 10:01 PM, Uwe Schindler wrote: I do it that way: - Checkout the backwards branch (not the tag) to trunk/tags/lucene_2_4_back_compat_tests. I have this checkout everytime there, I update it regularily together with trunk. - Place and leave a build.properties files with the following line in your trunk dir: "tag=lucene_2_4_back_compat_tests" - You can then test using ant test / test-tag and so on, the java property fixes the tag directory to your branch checkout. The good thing is, that you always have the last revision of branch and can modify and commit it directly. - If everything is ok, do a tag from your checked out branch (svn copy .) and then update the main common-build.xml I was always wondering: Why do we need tags for the backwards tests? Why not just automatically checkout the revision equal to the current trunk revision for testing (what I did manually)? Currently we always have to create a new tag after each commit to backwards branch, this is somehow strange (ok, by that you fix the revision used for testing this trunk checkout, but if you checkout the same revision no in the backwards branch that trunk currently has, it would always be correctly related). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de> http://www.thetaphi.de eMail: u...@thetaphi.de _ From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Wednesday, July 29, 2009 6:24 PM To: java-dev@lucene.apache.org Subject: backwards compat tests Is their a wiki page on how to handle updating the back compat tests? I found some mail regarding it, but most of what I found was older. The latest I saw talked about the separate branch, and updating that branch with fixes if you need too - but I see now it seems to work with tags? Do I update the branch, tag it with the current date, then update the build file to point to the new tag (compatibility.tag)? -- - Mark http://www.lucidimagination.com
Re: backwards compat tests
Uwe - I asked this question a while ago on LUCENE-1529 and this is an answer Mike gave: http://issues.apache.org/jira/browse/LUCENE-1529?focusedCommentId=12699177&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12699177 I think it's related to what you ask Shai On Wed, Jul 29, 2009 at 10:01 PM, Uwe Schindler wrote: > I do it that way: > > > > - Checkout the backwards branch (not the tag) to > trunk/tags/lucene_2_4_back_compat_tests. I have this checkout everytime > there, I update it regularily together with trunk. > > - Place and leave a build.properties files with the following > line in your trunk dir: “tag=lucene_2_4_back_compat_tests” > > - You can then test using ant test / test-tag and so on, the java > property fixes the tag directory to your branch checkout. The good thing is, > that you always have the last revision of branch and can modify and commit > it directly. > > - If everything is ok, do a tag from your checked out branch (svn > copy …) and then update the main common-build.xml > > > > I was always wondering: Why do we need tags for the backwards tests? Why > not just automatically checkout the revision equal to the current trunk > revision for testing (what I did manually)? Currently we always have to > create a new tag after each commit to backwards branch, this is somehow > strange (ok, by that you fix the revision used for testing this trunk > checkout, but if you checkout the same revision no in the backwards branch > that trunk currently has, it would always be correctly related). > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > -- > > *From:* Mark Miller [mailto:markrmil...@gmail.com] > *Sent:* Wednesday, July 29, 2009 6:24 PM > *To:* java-dev@lucene.apache.org > *Subject:* backwards compat tests > > > > Is their a wiki page on how to handle updating the back compat tests? I > found some mail regarding it, but most of what I found was older. The latest > I saw talked about the separate branch, and updating that branch with fixes > if you need too - but I see now it seems to work with tags? > > > > Do I update the branch, tag it with the current date, then update the build > file to point to the new tag (compatibility.tag)? > > -- > - Mark > > http://www.lucidimagination.com >
RE: backwards compat tests
I do it that way: - Checkout the backwards branch (not the tag) to trunk/tags/lucene_2_4_back_compat_tests. I have this checkout everytime there, I update it regularily together with trunk. - Place and leave a build.properties files with the following line in your trunk dir: "tag=lucene_2_4_back_compat_tests" - You can then test using ant test / test-tag and so on, the java property fixes the tag directory to your branch checkout. The good thing is, that you always have the last revision of branch and can modify and commit it directly. - If everything is ok, do a tag from your checked out branch (svn copy .) and then update the main common-build.xml I was always wondering: Why do we need tags for the backwards tests? Why not just automatically checkout the revision equal to the current trunk revision for testing (what I did manually)? Currently we always have to create a new tag after each commit to backwards branch, this is somehow strange (ok, by that you fix the revision used for testing this trunk checkout, but if you checkout the same revision no in the backwards branch that trunk currently has, it would always be correctly related). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de> http://www.thetaphi.de eMail: u...@thetaphi.de _ From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Wednesday, July 29, 2009 6:24 PM To: java-dev@lucene.apache.org Subject: backwards compat tests Is their a wiki page on how to handle updating the back compat tests? I found some mail regarding it, but most of what I found was older. The latest I saw talked about the separate branch, and updating that branch with fixes if you need too - but I see now it seems to work with tags? Do I update the branch, tag it with the current date, then update the build file to point to the new tag (compatibility.tag)? -- - Mark http://www.lucidimagination.com
Re: backwards compat tests
I think it's not documented anywhere... roughly these are the steps: * Make mods to tags/lucene_2_4_.../* so "ant test-tag" passes * Use "svn switch" to switch that tags checkout from a "tag" to the 2_4 back compat branch * Commit from that dir & plant a new tag * Update common-build.xml to point to the new tag * Maybe run "ant test-tag" again and confirm everything passes * Commit at the top level Mike On Wed, Jul 29, 2009 at 12:23 PM, Mark Miller wrote: > Is their a wiki page on how to handle updating the back compat tests? I > found some mail regarding it, but most of what I found was older. The latest > I saw talked about the separate branch, and updating that branch with fixes > if you need too - but I see now it seems to work with tags? > Do I update the branch, tag it with the current date, then update the build > file to point to the new tag (compatibility.tag)? > > -- > - Mark > > http://www.lucidimagination.com > > - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
backwards compat tests
Is their a wiki page on how to handle updating the back compat tests? I found some mail regarding it, but most of what I found was older. The latest I saw talked about the separate branch, and updating that branch with fixes if you need too - but I see now it seems to work with tags? Do I update the branch, tag it with the current date, then update the build file to point to the new tag (compatibility.tag)? -- - Mark http://www.lucidimagination.com
