"back_compat" folders in tags when I SVN update
Hi folks, Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well over 100 so far) when I SVN update? Thanks. -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: "back_compat" folders in tags when I SVN update
This is how we run our back-compat tests. Ie, when you run "ant test-tag", it will checkout the current back-compat tag into tags/, and run those tests against current trunk. This catches us if we accidentally break back-compat. Sometimes changes to trunk require acceptable changes to back-compat tests, eg, if a given test was using an internal API, or we decided to make an exception to back-compat, etc. In this case, the tag (which is stored in common-build.xml, as compatibility.tag) is advanced. So, if you keep a long checkout, over time you'll accumulate lots of these dirs under tags. You can safely remove all of them (or, all but the most recent).. Mike On Tue, Jan 5, 2010 at 12:19 AM, George Aroush wrote: > Hi folks, > > Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well > over 100 so far) when I SVN update? > > Thanks. > > -- George > > > - > 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: "back_compat" folders in tags when I SVN update
: Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well : over 100 so far) when I SVN update? Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/"; checked out in it's entirety? That seems ... problematic. New tags/branches could be created at anytime -- it's even possibly to have Hudson autotag every build if we wanted. Server side these tags are essentially "free" but if you checkout at the top level you pay the price of local storage on update. I would rethink your checkout strategy. -Hoss - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: "back_compat" folders in tags when I SVN update
I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and http://svn.apache.org/repos/asf/lucene/java/tags/ checked out. I think having all this "back_compat" folders, under the "tags" can be very confusing, especially for someone who looks in "tags" in search of a released version and finds all the "back_compat" folders not knowing what they mean (there is more "back_compat" folders than actually release tags!) If we are using "tags" for back-compat testing, aren't we overloading the meaning of the "tags" folder? I prefer to see "tags" used for what it is, a place to park an actually released; it shouldn't be used for testing or its content changed dynamically. -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Tuesday, January 05, 2010 3:21 PM To: java-dev@lucene.apache.org Subject: Re: "back_compat" folders in tags when I SVN update : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well : over 100 so far) when I SVN update? Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/"; checked out in it's entirety? That seems ... problematic. New tags/branches could be created at anytime -- it's even possibly to have Hudson autotag every build if we wanted. Server side these tags are essentially "free" but if you checkout at the top level you pay the price of local storage on update. I would rethink your checkout strategy. -Hoss - 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: "back_compat" folders in tags when I SVN update
In my opinion, the back-compat tags are not really needed. The checkout command for test-tag should simply use a revision number to checkout. Whenever you commit something in the backwards branch, you set the revision number in common-build.xml and you are done. No need for a extra tag, for me this was always not clear, why we need tags. What do others think? I could change the build script to do this. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: George Aroush [mailto:geo...@aroush.net] > Sent: Wednesday, January 06, 2010 6:00 AM > To: java-dev@lucene.apache.org > Subject: RE: "back_compat" folders in tags when I SVN update > > I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and > http://svn.apache.org/repos/asf/lucene/java/tags/ checked out. > > I think having all this "back_compat" folders, under the "tags" can be > very > confusing, especially for someone who looks in "tags" in search of a > released version and finds all the "back_compat" folders not knowing what > they mean (there is more "back_compat" folders than actually release > tags!) > If we are using "tags" for back-compat testing, aren't we overloading the > meaning of the "tags" folder? > > I prefer to see "tags" used for what it is, a place to park an actually > released; it shouldn't be used for testing or its content changed > dynamically. > > -- George > > -Original Message----- > From: Chris Hostetter [mailto:hossman_luc...@fucit.org] > Sent: Tuesday, January 05, 2010 3:21 PM > To: java-dev@lucene.apache.org > Subject: Re: "back_compat" folders in tags when I SVN update > > > : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories > (well > : over 100 so far) when I SVN update? > > Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/"; > checked out in it's entirety? > > That seems ... problematic. New tags/branches could be created at anytime > -- it's even possibly to have Hudson autotag every build if we wanted. > Server side these tags are essentially "free" but if you checkout at the > top level you pay the price of local storage on update. > > I would rethink your checkout strategy. > > > > > -Hoss > > > - > 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 - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: "back_compat" folders in tags when I SVN update
+1 I don't like the tags either. Michael On 1/6/10 10:49 AM, Uwe Schindler wrote: In my opinion, the back-compat tags are not really needed. The checkout command for test-tag should simply use a revision number to checkout. Whenever you commit something in the backwards branch, you set the revision number in common-build.xml and you are done. No need for a extra tag, for me this was always not clear, why we need tags. What do others think? I could change the build script to do this. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: George Aroush [mailto:geo...@aroush.net] Sent: Wednesday, January 06, 2010 6:00 AM To: java-dev@lucene.apache.org Subject: RE: "back_compat" folders in tags when I SVN update I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and http://svn.apache.org/repos/asf/lucene/java/tags/ checked out. I think having all this "back_compat" folders, under the "tags" can be very confusing, especially for someone who looks in "tags" in search of a released version and finds all the "back_compat" folders not knowing what they mean (there is more "back_compat" folders than actually release tags!) If we are using "tags" for back-compat testing, aren't we overloading the meaning of the "tags" folder? I prefer to see "tags" used for what it is, a place to park an actually released; it shouldn't be used for testing or its content changed dynamically. -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Tuesday, January 05, 2010 3:21 PM To: java-dev@lucene.apache.org Subject: Re: "back_compat" folders in tags when I SVN update : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well : over 100 so far) when I SVN update? Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/"; checked out in it's entirety? That seems ... problematic. New tags/branches could be created at anytime -- it's even possibly to have Hudson autotag every build if we wanted. Server side these tags are essentially "free" but if you checkout at the top level you pay the price of local storage on update. I would rethink your checkout strategy. -Hoss - 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 - 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: "back_compat" folders in tags when I SVN update
+1 using a svn revision would make things cleaner. (3 positive german votes :) simon On Wed, Jan 6, 2010 at 11:00 AM, Michael Busch wrote: > +1 > > I don't like the tags either. > > Michael > > On 1/6/10 10:49 AM, Uwe Schindler wrote: >> >> In my opinion, the back-compat tags are not really needed. The checkout >> command for test-tag should simply use a revision number to checkout. >> Whenever you commit something in the backwards branch, you set the >> revision >> number in common-build.xml and you are done. No need for a extra tag, for >> me >> this was always not clear, why we need tags. >> >> What do others think? I could change the build script to do this. >> >> - >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> >>> >>> -Original Message- >>> From: George Aroush [mailto:geo...@aroush.net] >>> Sent: Wednesday, January 06, 2010 6:00 AM >>> To: java-dev@lucene.apache.org >>> Subject: RE: "back_compat" folders in tags when I SVN update >>> >>> I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and >>> http://svn.apache.org/repos/asf/lucene/java/tags/ checked out. >>> >>> I think having all this "back_compat" folders, under the "tags" can be >>> very >>> confusing, especially for someone who looks in "tags" in search of a >>> released version and finds all the "back_compat" folders not knowing what >>> they mean (there is more "back_compat" folders than actually release >>> tags!) >>> If we are using "tags" for back-compat testing, aren't we overloading the >>> meaning of the "tags" folder? >>> >>> I prefer to see "tags" used for what it is, a place to park an actually >>> released; it shouldn't be used for testing or its content changed >>> dynamically. >>> >>> -- George >>> >>> -Original Message- >>> From: Chris Hostetter [mailto:hossman_luc...@fucit.org] >>> Sent: Tuesday, January 05, 2010 3:21 PM >>> To: java-dev@lucene.apache.org >>> Subject: Re: "back_compat" folders in tags when I SVN update >>> >>> >>> : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories >>> (well >>> : over 100 so far) when I SVN update? >>> >>> Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/"; >>> checked out in it's entirety? >>> >>> That seems ... problematic. New tags/branches could be created at >>> anytime >>> -- it's even possibly to have Hudson autotag every build if we wanted. >>> Server side these tags are essentially "free" but if you checkout at the >>> top level you pay the price of local storage on update. >>> >>> I would rethink your checkout strategy. >>> >>> >>> >>> >>> -Hoss >>> >>> >>> - >>> 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 >>> >> >> >> - >> 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 > > - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: "back_compat" folders in tags when I SVN update
I'll open an issue when I am back in Bremen.
I tried a little bit with svn and found out:
- We just give the rev number in common-build in syntax backwards-rev="-r
". By that you can use ant -Dbackwards-rev="" to force test-tag (we
should rename that to "test-backwards" and keep a test-tag with dependency
to that for compatibility).
- The checkout on backwards creates a directory
"backwards/${backwards-branch}" and uses "svn co ${backwards-rev} http://...
'backwards/${backwards-branch}'". The cool thing, the dir is checked out if
non existent, but if the checkout already exists, svn co implicitely does an
svn up to the given revision (it will also downgrade and merge if newer). So
the test-backwards target always updates the checkout to the correct
revision. I had not tried with local changes, but this should simply merge
as an svn up.
The workflow for committing fixes to bw would be:
- First use "svn up" to upgrade the backwards working copy to HEAD.
- Commit the changes
- Copy and paste the message "Committed revision " to common-build.xml
- Commit the changes in trunk
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
> Sent: Wednesday, January 06, 2010 11:03 AM
> To: java-dev@lucene.apache.org
> Subject: Re: "back_compat" folders in tags when I SVN update
>
> +1
> using a svn revision would make things cleaner.
>
> (3 positive german votes :)
>
> simon
>
> On Wed, Jan 6, 2010 at 11:00 AM, Michael Busch wrote:
> > +1
> >
> > I don't like the tags either.
> >
> > Michael
> >
> > On 1/6/10 10:49 AM, Uwe Schindler wrote:
> >>
> >> In my opinion, the back-compat tags are not really needed. The checkout
> >> command for test-tag should simply use a revision number to checkout.
> >> Whenever you commit something in the backwards branch, you set the
> >> revision
> >> number in common-build.xml and you are done. No need for a extra tag,
> for
> >> me
> >> this was always not clear, why we need tags.
> >>
> >> What do others think? I could change the build script to do this.
> >>
> >> -
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: u...@thetaphi.de
> >>
> >>
> >>>
> >>> -Original Message-
> >>> From: George Aroush [mailto:geo...@aroush.net]
> >>> Sent: Wednesday, January 06, 2010 6:00 AM
> >>> To: java-dev@lucene.apache.org
> >>> Subject: RE: "back_compat" folders in tags when I SVN update
> >>>
> >>> I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and
> >>> http://svn.apache.org/repos/asf/lucene/java/tags/ checked out.
> >>>
> >>> I think having all this "back_compat" folders, under the "tags" can be
> >>> very
> >>> confusing, especially for someone who looks in "tags" in search of a
> >>> released version and finds all the "back_compat" folders not knowing
> what
> >>> they mean (there is more "back_compat" folders than actually release
> >>> tags!)
> >>> If we are using "tags" for back-compat testing, aren't we overloading
> the
> >>> meaning of the "tags" folder?
> >>>
> >>> I prefer to see "tags" used for what it is, a place to park an
> actually
> >>> released; it shouldn't be used for testing or its content changed
> >>> dynamically.
> >>>
> >>> -- George
> >>>
> >>> -Original Message-
> >>> From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> >>> Sent: Tuesday, January 05, 2010 3:21 PM
> >>> To: java-dev@lucene.apache.org
> >>> Subject: Re: "back_compat" folders in tags when I SVN update
> >>>
> >>>
> >>> : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\
> directories
> >>> (well
> >>> : over 100 so far) when I SVN update?
> >>>
> >>> Are you saying you have "http://svn.apache.org/repos/asf/lucene/java/";
> >>> checked out in it's entirety?
> >>>
> >>> That seems ... problematic. New tags/branches could be created at
> >>> anytime
> >>&
RE: "back_compat" folders in tags when I SVN update
: I prefer to see "tags" used for what it is, a place to park an actually : released; it shouldn't be used for testing or its content changed : dynamically. I have no opinion about the rest of this thread (changing the back compat testing to use a specific revision on the previous release branch) but as for this specific comment: it's really a mistake to think of tags as only being for releases. the TTB convetion in svn (trunk, tags, branches) stems from what's considered a best practice when migrating from CVS: trunk corrisponds to MAIN in cvs, the branches directory corrisponds to the list of branching tags in CVS, and the tag directory corrisponds to the list of tags in CVS. there is nothing special about the concept of a CVS/SVN "tag" that should make it synonymous in peopls minds with a "release" ... yes we "tag" every release, but there are lots of other reasons to "tag" things in both CVS and SVN: release candidates are frequently taged, many other projects tag stable builds from their continuous integration system ... a developer could create an aritrary "checkpoint" tag to denote when there was a dramatic shift in development in a project in case people wnated to easily find when that shift happened so they could go back and fork a branch at that point if that approach was deemed unsuccessful. bottom line: not a good idea to assume all tags are releases. (that said: the TTB convetion is nothing more then a convention ... there's nothing to stop us from using a more verbose directory hierarchy to isolate "release tags" in a single place.. ./trunk ./branches/branch_a ./... ./tags ./tags/releases ./tags/releases/2_9_0 ./... ./tags/some_misc_tag ) -Hoss - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: "back_compat" folders in tags when I SVN update
Thanks for the clarification Chris. My key concern was that "tags" was becoming too crowded as-is, and important data is getting lost in the crowd. Looks like Uwe has a solution per https://issues.apache.org/jira/browse/LUCENE-2193. If this won't do, I like you suggestion of structuring "tags" per your example below. -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Wednesday, January 06, 2010 2:21 PM To: java-dev@lucene.apache.org Subject: RE: "back_compat" folders in tags when I SVN update : I prefer to see "tags" used for what it is, a place to park an actually : released; it shouldn't be used for testing or its content changed : dynamically. I have no opinion about the rest of this thread (changing the back compat testing to use a specific revision on the previous release branch) but as for this specific comment: it's really a mistake to think of tags as only being for releases. the TTB convetion in svn (trunk, tags, branches) stems from what's considered a best practice when migrating from CVS: trunk corrisponds to MAIN in cvs, the branches directory corrisponds to the list of branching tags in CVS, and the tag directory corrisponds to the list of tags in CVS. there is nothing special about the concept of a CVS/SVN "tag" that should make it synonymous in peopls minds with a "release" ... yes we "tag" every release, but there are lots of other reasons to "tag" things in both CVS and SVN: release candidates are frequently taged, many other projects tag stable builds from their continuous integration system ... a developer could create an aritrary "checkpoint" tag to denote when there was a dramatic shift in development in a project in case people wnated to easily find when that shift happened so they could go back and fork a branch at that point if that approach was deemed unsuccessful. bottom line: not a good idea to assume all tags are releases. (that said: the TTB convetion is nothing more then a convention ... there's nothing to stop us from using a more verbose directory hierarchy to isolate "release tags" in a single place.. ./trunk ./branches/branch_a ./... ./tags ./tags/releases ./tags/releases/2_9_0 ./... ./tags/some_misc_tag ) -Hoss - 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
