Not sure if this will help or not as I have never used it personally.
There is a small utility called SubWCRev.exe in the tortoisesvn website
http://tortoisesvn.tigris.org/download.html
Here is the text from the website about it.
SubWCRev.exe: a small command line tool which you can use in your build
steps. It takes a file as an argument and replaces all "$WCREV$" strings
with the revision of your working copy. This is usefull if you want to
include the Subversion revision in the version of your project. If you
need an example, check out the TortoiseSVN source.
Max Bowsher wrote:
>>>>Max Bowsher wrote:
>>>>
>>>>
>>>>>svnversion.
>>>>>
>>>>>
>>>Svenne Krap wrote:
>>>
>>>
>>>>Is there any way to use that like a keyword ?
>>>>
>>>>
>>Max Bowsher wrote:
>>
>>
>>>No. Because when you really start analysing the problem, you realize that
>>>this piece of information is very un-keyword-like. Principally in that it
>>>
>>>
>is
>
>
>>>information about a *tree* not a single file.
>>>
>>>
>
>Svenne Krap wrote:
>
>
>>I really don't see how this belonging to a tree makes it less
>>keyword-like. Why hasn't it been implemented as (say) $ TreeRevision: $
>>then ?
>>
>>
>
>Because doing so would require a major alteration to the way subversion
>handles working copies.
>After any update/switch/checkout operation, subversion would need to recurse
>both down and *up* through the directory structure seeking files with
>svn:keywords containing TreeRevision - *even* if the update was just on a
>single file. The cost of this is deemed unacceptable.
>
>
>
>>I frankly never understood the rationale for having mixed
>>revisionnumbers in a WC,
>>
>>
>
>"svn up" in a subdirectory, to save time, when you only need to update the
>part you are working on.
>
>"svn switch" of a part of a working copy, when you want to work on a certain
>module of code, whilst continuing to track the trunk for other modules.
>
>"svn up -r oldrev program" to run the current testsuite against an old
>program version, to verify that the tests are detecting the old bugs
>correctly.
>
>"svn ci file1" when someone else has modified and committed some other file
>meanwhile. If subversion couldn't represent mixed revision WCs, it would
>have to force you to update your entire WC to HEAD before allowing you to
>commit *anything*.
>
>
>
>>for me, the revisionnumber shows the version of
>>the "package" not the file.
>>
>>
>
>A revision number does indicate the version of the "package". And the
>package version a file last changed in is a convenient way to label a
>particular version of a file.
>
>
>
>>I actually think the "*Global Revision
>>Numbers"* part of the SVNBook agrees with me here... I might be sleepy
>>right now (it's bedtime soon), but is you rationale for not having this
>>"treerevision" not directly contradictionary to the whole idea of global
>>revision numbers ? Let me quote the SVNbook "Subversion's revision
>>numbers apply to /entire trees/, not individual files", that tells me
>>there should be a way to get the current revision of the file (not the
>>latest revision, where this file was modified).
>>
>>
>
>You can get the current revision of a file (svn info), but there is
>absolutely no guarantee that it means anything about the state of the tree,
>for reasons given above.
>
>
>Max.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
Received on Mon May 3 00:48:28 2004