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
>>>>
>>>>
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Jul 17 2006 - 13:41:32 EDT