[build] svn-prop and svn-info targets (was Re: general: error in build: missing release.properties)

[Mark Hindess <ma...@googlemail.com>]

On 3 March 2008 at 9:30, Tim Ellison <t....@gmail.com> wrote:
> Stepan Mishura wrote:
> > On 3/3/08, Alexey Varlamov <al...@gmail.com> wrote:
> >> 2008/3/2, Gregory Shimansky <gs...@apache.org>:
> >>> On 2 ÍÁÒÔÁ 2008 Francis ANDRE wrote:
> >>>> Done: HARMONY-5560
> >>>>
> >>>>  > Maybe as simple as setting that env var in our scripts when exec'ing 
> the
> >>>>  > svn command.
> >>>>
> >>>> Yes, it should work
> >>> In fact I reported the same problem a while ago in HARMONY-5256 when I
> >>> resolved the bug with DRLVM working on localized Chinese winXP. The probl
> em
> >>> is the same, federated build could not parse SVN root and revision. I won
> der
> >>> if switching to "svn info --xml" would help. This would require quite mod
> ern
> >>> subversion client which supports --xml switch.
> >> Yes, I think --xml should help. I utilized it in common-resources
> >> infra, and seems it worked w/o complaints.
> >> "'svn info --xml " support was added since v1.3.0 (Dec 2005) [1],
> >> which is not too strict requirement I believe.
> >>
> > 
> > Another alternative would be using SvnAnt [1]. I haven't tried the
> > task yet but it looks promising: as I understood its docs. it should
> > help us to avoid exec-ing svn and parsing svn output.
> > 
> > Have anyone experience with it? Any feedback?
> > 
> > [1] http://subclipse.tigris.org/svnant.html
> 
> 
> I'd rather use --xml than introduce a new dependency in our tooling.

+1

Another thing that would be brilliant to consolidate (or at least make
them the same!) the several different versions of svn-prop and svn-info
tasks.  For instance, there are versions in at least:

  build.xml
  working_jdktools/make/properties.xml
  working_classlib/make/properties.xml
  common_resources/build/properties.xml
  common_resources/make/properties.xml

Also, I think it might be better to combine the svn-info target with the
svn-prop target rather than having two targets for svn-related calls and
to speed things up in the case were we already have the svn.revision - i.e.
in components of the federation build and in modules of a full classlib build[0] - we should protect the targets with:

  unless="svn.revision"

to avoid the extra (redundant[0]) calls to svn.

-Mark.

[0] redundant because, like all ant properties, svn.revision et al are
    immutable once defined so the subsequent svn calls don't change the
    value.