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
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 busch...@gmail.com 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 busch...@gmail.com 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
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
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/tag name, 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 geo...@aroush.net 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
