At least I have to install svn for that.
Uli
Am 18.07.2006 um 11:18 schrieb Anjo Krank:
> 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 - 06:09:44 EDT