subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <>
Subject SVN Keywords...
Date Tue, 26 Oct 2010 19:55:43 GMT
I have a series of projects that operate as service daemons; all the projects 
have a simple main.cpp that loads another class that does the actual work. So I 
never have to touch main.cpp except when I go to make a release, and then only 
to update a couple things: version numbers and dates.

I'd like to try to automate the data modifications a little bit more; and while 
SVN has the $Date$ keyword, aka $LastChangedDate$; that's not quite correct for 
what I want to do - svn after, all svn won't detect a change if there are no 
actual modifications on the file (e.g. "touch somefile.cpp" won't result in a 
delta in svn), at least as explained in the svn red book[1].

Would it be possible to have a $LastCommitDate$, and perhaps a 
$LastCommitRevision$ that is not file specific but name space specific, since 
SVN operates on name spaces (e.g. ^/some/svn/path) instead of files ( 
^/some/svn/path/some.file.with.extension)? Or perhaps $LastUrlCommit...$.

In either case the specified name space should likely be the URL/namespace where 
the file is located, perhaps with an option to have the base URL when it was 
checked out/exported.
This could be provided using arrays, for example $LastCommitDate[0]$ could be 
the base URL while $LastCommitDate[1]$ is the URL of the file.

For the svn:externals use-case, the URL would be related to the external, not to 
the project pulling the URL in. So suppose the following:
Project located at /myproject/trunk, pulls in an svn:external from 
/myotherproject/tags as lib1; the proposed keyword set would apply to 
/myproject/trunk only for files that actually exist in the repository under that 
URL, while the proposed keywords for the files checked out/exported to lib1, 
which are located under /myotherproject/tags, would apply the URL of the 
external - /myotherproject/tags and not /myproject/trunk.

While I understand the logic present in the $GlobaRevision$ section on in the 
SVN Redbook[1], there is also some problems with the suggested resolution when 
trying to do the same thing on multiple platforms, namely and especially MS 
Windows where processing of 'svnversion' output is impossible with standard 
tools on the platform to say the least.



View raw message