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 ?
A whole tree might be a "single file" (or unit) logically (for example
LaTeX documents, or perhaps a PHP website - not everything uses/has a
build system)
Especially the SVNParentPath directive for Apache2 kinda encourages to
use a lot of repositories this style (at least for me :)
I frankly never understood the rationale for having mixed
revisionnumbers in a WC, for me, the revisionnumber shows the version of
the "package" not the 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).
Svenne
Max Bowsher wrote:
>>Max Bowsher wrote:
>>
>>
>>>svnversion.
>>>
>>>
>
>Svenne Krap wrote:
>
>
>>Is there any way to use that like a keyword ?
>>
>>
>
>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.
>
>
>
>>Or any fancy way to include that automaticly ?
>>
>>
>
>Use it in your build system.
>
>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:03:12 2004