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
XXXX". 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 XXXX" 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...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
