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. Ben [1]http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
