>>> Max Bowsher wrote:
>> 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
>> 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
"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
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 3 00:27:22 2004