> I would like to know if anyone has asked for this before and, if so, what
> the answer/solution was?
> I am a developer on a C++ project hosted on SourceForge.net, which uses
> Subversion as its repository. I would like the Subversion repository to
> mimic the antics of TortoiseSVN's program "SubWCRev.exe" automatically.
Yes, even so often someone decided to write a FAQ about it:
But, it's also hard to implement (efficiently), given mixed revision
> By this I mean that I would have two members in the source ("version.in" and
> "version.h") with "version.in" being (less my comments):
> #define FILEVER 3, 4, 0, $WCREV$
> #define PRODUCTVER 3, 4, 0, $WCREV$
> #define STRFILEVER "3, 4, 0, $WCREV$\0"
> #define STRPRODUCTVER "3, 4, 0, $WCREV$\0"
> What I would like is that when anyone commits anything to this project,
> Subversion copies "version.in" to "version.h" (overwriting it if it exists)
> whilst it substitutes the $WCREV$ (or differently named keyword to be
> distinct from TortoiseSVN's program) with the current revision number (if
> "version.in" is changed during the commit, then it would be copied after the
> change has been committed).
> During the commit process, the new "version.h" would be sent back to the
> user committing his/her change so that their working copy is identical to
> that stored in the repository.
Well, there's no such thing as 'send back to the user' in a commit
process, but it could be done in post-commit. However not without
scanning the full source tree, which comes at a (very large) cost
> This way "version.h" always has the current build number in it should anyone
> Checkout the project.
> This differs from the current $Rev$ keyword in that the whole field is
> replace by a numeric value rather than inserting the revision number after
> the "$Rev:" string i.e.:
> #define FILEVER 3, 4, 0, $Rev$:
> would become
> #define FILEVER 3, 4, 0, $Rev: nnnn$:
> which is not a valid C statement. This would not be a problem for future
> updates as the source file ("version.in") was not altered.
> It also differs from the SubWCRev program which would, in the process of
> updating "version.h" mark the directory as updated and hence now different
> from the repository.
> I would envision a different keyword associated with the "version.in" file
> in the Subversion repository - something like $Rev$ but meaning replacing
> the whole keyword string with the revision number and specifying the name of
> the file to be replaced (in my case "version.h").
> If anyone has an alternative solution, I would be grateful to hear.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 31 00:20:55 2006