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.
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
This could be provided using arrays, for example $LastCommitDate$ could be
the base URL while $LastCommitDate$ 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, 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.
Received on 2010-10-26 21:56:24 CEST