It might just be my opinion, but...
I think this is a very overengineered solution to a problem, and will
add lots of additional complexity in the working copy code.
If the point is to have a version for customer/user reporting, why not
base it on repository path rather than revision number? Is making a tag
and switching over to it really that hard? With a tag you are reporting
every version of every file, and tagging implies a release process.
Developers who insist on giving customers/users non-tagged code which is
potentially from a mixed-revision repository should just write a script
to supply the version number during their deployment through svnversion.
Am I missing something?
-David Waite
e.huelsmann@gmx.net wrote:
>>>Suppose the file with the expandable keyword is "conf/revfile" (below
>>>trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
>>>build a release that includes one patch, the buildmeister does:
>>>
>>> cd trunk/ # or branches/whatever, or ....
>>> svn up -r 1234 # includes conf/revfile, so it gets 1234
>>> svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
>>>
>>>Now revfile says "1234", but svnversion on "." would say "1234:2345",
>>>which I think is not what anyone would want.
>>>
>>>
>>That is just the same as if you had a manually maintained "VERSION.TXT"
>>file in the root of the project, and updated only a sub-tree. VERSION.TXT
>>would be out of date. If you put VERSION.TXT in the sub-tree, then it
>>
>>
>would
>
>
>>have been updated ... regardless of whether it was manually maintained or
>>using this new keyword. The system works exactly as designed and as
>>expected. I think that is reasonable behaviour.
>>
>>
>
>Yay Julian! Go!
>
>Well on a serious note: This is what I wanted to add to subversion when I
>first started hacking it. (Only a few months ago) I never got round to doing
>it,
>but I do think this is reasonable, especially where the argument of the
>keyword
>is '.'.
>
>bye,
>
>
>Erik.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 8 22:53:47 2003