Uh, doesn't everyone have it already? And how would you get the code
in the first place if you didn't? And what would you do with it? This
snippet would run the on server that does the checkout and packaging.
And given that we'd need yet another beta-only-for-us package, I
think a one-liner makes more sense?
Cheers, Anjo
Am 18.07.2006 um 11:03 schrieb Ulrich Köster:
> Yes, but you have to install svn for that.
>
> Uli
> Am 18.07.2006 um 10:51 schrieb Anjo Krank:
>
>> FWIW, isn't this the same as:
>>
>> echo >buildserver.version 2.0.0.`svn info|grep Revision|cut -d '
>> ' -f 2`
>>
>> Cheers, Anjo
>>
>> Am 18.07.2006 um 10:47 schrieb Ulrich Köster:
>>
>>> I'm ready to add it to the svn but I need the license for the
>>> jars first. Where can I find it.
>>>
>>> Uli
>>> Am 17.07.2006 um 23:31 schrieb Pierre Frisch:
>>>
>>>> I have tested it and the code included will do the right thing
>>>> i.e. the build will have the version number 2.0.0.svnNumber
>>>> svnNumber being the latest revision of the repository that was
>>>> used to build that version. That way we can know exactly which
>>>> changes were included in which build.
>>>>
>>>> As our current build number are way bellow our svn revision
>>>> numbers this change will be transparent for everyone.
>>>>
>>>> The only caveat is that you need to use the latest JavaSVN
>>>> libraries as there is a fix in HEAD specially for us.
>>>>
>>>> Just try it. The build number will change if there is something
>>>> new that has been committed and will not change if nothing new
>>>> is there.
>>>>
>>>> Pierre
>>>>
>>>> On 17-Jul-06, at 7:41 PM, Ken Anderson wrote:
>>>>
>>>>> In Subversion, any file changing in the entire work area
>>>>> creates a new revision. If you change 10 files and commit them
>>>>> at the same time, the entire work area gets its revision number
>>>>> bumped up by 1.
>>>>>
>>>>> On Jul 17, 2006, at 1:23 PM, Mike Schrag wrote:
>>>>>
>>>>>> Totally my subversion ignorance here ... In CVS, each file has
>>>>>> its own history of revision numbers. In SVN, I take it that
>>>>>> each unique set of checked out files has a version number? So
>>>>>> in CVS, the equivalent of this number would only change if you
>>>>>> modified the build.xml file, but it sounds like SVN is cooler
>>>>>> than that?
>>>>>>
>>>>>> So the build server keeps a checked out version and just
>>>>>> updates it each night. Would that workflow behave properly
>>>>>> with respect to the number changing when we build? This
>>>>>> definitely sounds like a smarter approach in general.
>>>>>>
>>>>>> ms
>>>>>>
>>>>>> On Jul 17, 2006, at 11:25 AM, Pierre Frisch wrote:
>>>>>>
>>>>>>> Is there a reason why we don't use the svn version numbers?
>>>>>>> This would make it a lot easier to track the version of the
>>>>>>> source code that goes with the current build.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Pierre
>>>>>>>
>>>>>>> On 3-Jul-06, at 10:13 PM, Pierre Frisch wrote:
>>>>>>>
>>>>>>>> We can also do it that way using javasvn:
>>>>>>>>
>>>>>>>> <!-- ========================================== -->
>>>>>>>> <!-- Load version provided by
>>>>>>>> buidserver. -->
>>>>>>>> <!-- ========================================== -->
>>>>>>>> <target name="load.version.file">
>>>>>>>> <property name="repository.URL" value="${basedir}" />
>>>>>>>> <java classname="org.tmatesoft.svn.cli.SVN" dir="$
>>>>>>>> {basedir}" fork="true" failonerror="true"
>>>>>>>> output="svninfo.xml" logError="true">
>>>>>>>> <arg value="info" />
>>>>>>>> <arg value="${repository.URL}" />
>>>>>>>> <arg value="--xml" />
>>>>>>>> <classpath>
>>>>>>>> <pathelement location="${project.lib.dir}/ganymed.jar" />
>>>>>>>> <pathelement location="${project.lib.dir}/javasvn.jar" />
>>>>>>>> <pathelement location="${project.lib.dir}/javasvn-
>>>>>>>> cli.jar" />
>>>>>>>> </classpath>
>>>>>>>> </java>
>>>>>>>> <xmlproperty file="svninfo.xml" prefix="svn" />
>>>>>>>> <delete file="svninfo.xml" quiet="true" />
>>>>>>>> <property name="build.version" value="2.0.0.$
>>>>>>>> {svn.info.entry(revision)}" />
>>>>>>>> <echo>version: ${build.version}</echo>
>>>>>>>> <!-- <loadfile property="build.version"
>>>>>>>> srcFile="buildserver.version" /> -->
>>>>>>>> </target>
>>>>>>>>
>>>>>>>> This uses the latest version of javasvn i.e. head as I had
>>>>>>>> to get a bug fixed for it to work, and we need to add the
>>>>>>>> three jars in the lib. I have included the right version.
>>>>>>>>
>>>>>>>> As it is a pure Java implementation it should work on all
>>>>>>>> platforms.
>>>>>>>>
>>>>>>>> Pierre
>>>>>>>>
>>>>>>>> <ganymed.jar>
>>>>>>>> <javasvn-cli.jar>
>>>>>>>> <javasvn.jar>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22-May-06, at 10:42 AM, Mike Schrag wrote:
>>>>>>>>
>>>>>>>>> echo -n does it
>>>>>>>>>
>>>>>>>>> On May 22, 2006, at 1:39 PM, Anjo Krank wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 22.05.2006 um 19:07 schrieb Mike Schrag:
>>>>>>>>>>
>>>>>>>>>>> I like this idea ...
>>>>>>>>>>>
>>>>>>>>>>> On May 22, 2006, at 10:19 AM, Anjo Krank wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Wouldn't is be easier to just take the svn repository
>>>>>>>>>>>> version that was active when the build started?
>>>>>>>>>>>>
>>>>>>>>>>>> echo 2.0.0.`svn info|grep Revision|cut -d ' ' -f 2`
>>>>>>>>>>>> >buildserver.version
>>>>>>>>>>>>
>>>>>>>>>>>> -->2.0.0.2709
>>>>>>>>>>
>>>>>>>>>> Except that it puts a ^J at the end of the version and ant
>>>>>>>>>> appends it to the build number... is there a "chop" for
>>>>>>>>>> the shell or some one-liner in perl?
>>>>>>>>>>
>>>>>>>>>> Cheers, Anjo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> Mit freundlichen Grüßen
>
> Ulrich Köster
>
> Assense Software Solutions GmbH
> Stadtdeich 27
> 20097 Hamburg
>
> Fernsprecher: +49 (0)40 3037579-0
> Fernkopierer: +49 (0)40 3037579-9
>
>
>
>
This archive was generated by hypermail 2.0.0 : Tue Jul 18 2006 - 05:18:49 EDT