Latest version of project vs. latest version of repository?

[Luke Pacholski]

We currently have Hudson setup to build WAR and EAR files (WAR gets
built in one build, then the EAR gets built, including the WAR) for
deployment to Websphere. I'm getting around to integrating svntask
into our build scripts to inject the SVN revision into the manifests.
It's working, but rather than giving me the revision of the project,
it's giving me the revision of the repository. I.e., if I check in one
project at r1 and then check into another, unrelated project at r2 and
do builds on both, Hudson reports r1 and r2 respectively, but svntask
is returning r2 for both.

I realize from a technical standpoint this isn't necessarily wrong
(checking out r2 of the first project would be no different than
checking out r1, since that project had no changes in r2), but it can
be mildly confusing at times. Is there a way (either via a
configuration option I'm missing or a code change) to get the latest
version of the *project*, rather than the *repository*?

Here's what I've been doing:

<target name="version" depends="init" >
<typedef resource="com/googlecode/svntask/svntask.xml">
<classpath>
<fileset dir="${lib.dir}/lib">
<include name="svnkit.jar" />
<include name="svntask.jar"/>
</fileset>
</classpath>
</typedef>

<svn>
<info path="${basedir}" revisionProperty="revisionVersion" />
</svn>

<property name="svn.revision" value="${revisionVersion}" />
</target>

<manifest>
<attribute name="SVN-Revision" value="${svn.revision}"/>
<attribute name="Built-By" value="${user.name}"/>
<attribute name="Build-Date" value="${DATE_TIME}"/>
</manifest>

Thanks.

Luke

[Jon Stevens]

I hear you. It wasn't a use case for me. Feel free to submit a patch
as an issue on googlecode.

Oh and I'd say that this project is dead. Everyone should move to git
(I also highly recommend github). This is an article I wrote about
why...

http://lookfirst.com/2011/04/subversion-mistake.html

I know that isn't always possible, but really... this is your crown
jewels. You might want to focus on keeping them safe.

jon

[Luke Pacholski]

I can certainly look into a patch, but do you have any idea where a
starting point would be to look?

As much as moving to git may be ideal, we moved from CVS to SVN two
years ago and it would probably take two years go convince the powers
that be to make the switch and actually do it. That is to say, for now
I just want to make SVN work as well as possible. For the most part,
it has been fine for what we've been using it for.

Luke

[Jon Stevens]

The source code is all pretty trivial. It is just a thin wrapper
around the svnkit.jar.

http://code.google.com/p/svntask/source/browse/trunk/src/com/googlecode/svntask/command/Info.java

jon

[Luke Pacholski]

Ok, no need for a patch. I just needed to use
committedRevisionProperty, instead of revisionProperty:

<svn>
<info path="${basedir}" committedRevisionProperty="revisionVersion" />
</svn>

That takes care of it...

Luke

[Jon Stevens]

Sweet. Shows how much I know. ;-)

jon

[Luke Pacholski]

Yeah, once I looked in Info.java, I thought "that *must* be it!", but
then got a little confused on how everything was wired up. Of course,
now it all makes perfect sense.

I realize this is basically dead, but would it be worthwhile to update
the usage section on the home page to note the difference between
revisionProperty and committedRevisionProperty? Maybe I'm wrong, but
I'm guessing most folks are actually interested in
committedRevisionProperty.

Luke