> 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:
http://subversion.tigris.org/faq.html#version-value-in-source
But, it's also hard to implement (efficiently), given mixed revision
working copies:
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
> 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
(time)...
> 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.
>
> Thanks
>
> David.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 31 00:20:55 2006