Subversion hooks modifying file AssemblyInfo

[Squirrelington]

Here is my conundrum, I have a Visual Basic.NET project, I want the revision of the project to match that of the svn revision and to be updated dynamically but the only solutions I have found that 'work' without fault have to be installed on any computer that is going to work against the source code.

I.e. addition projects (such as using MSBuilds, svnRevisionlabeller, ...) or SubWCRev.exe (as in TortoiseSVN). All of which won't work if someone else uses a different svn client or I'd rather not have to import or use additional programs in my build process if I can use hooks in the repository itself to just update the AssemblyInfo file with the newest revision number.

Does anyone have any suggestions or am I just going to have to give in and use one of these solutions I listed earlier (leaning toward SubWCRev.exe)?

p.s. I am aware of the issues involved in modifying the content of a commit via hooks (and the working copy on the committing computer will not match, which is why I haven't attempted this yet).

[georgevella]

Dunno if I understood your requirement correctly (+ its 2:23 in the morning here), but why don't you automate the build process. When the build server retrieves the code from source control, set it up to update the assemblyinfo files accordingly (for example we use a date/time + revision versioning scheme so the build server updates the assembly info files (and some C++ resources) to match this scheme). Basically we never store version information in svn, its autogenerated on every build. That way we avoid the problem where the code in svn is different than the code on the dev's machine. Also, the build server would generally use the default command line client so it does not matter whether you guys use tortoisesvn or ankh to access svn.

[Squirrelington]

The way it is setup is anyone can check out the source code, there is no build server, only subversion+apache for source control. Anyone with Visual Studio can check it out and build it but AssemblyInfo.vb is the file generated by the Solution that holds the versioning info for the compiled application and it is updated by Visual Studio separately than the subversion revision number.

Example: AssemblyInfo version is set at 4.1.0.2, i can make all the changes I want and save and compile and it doesn't change (except I can set the build number to increment) whereas the svn commit increments the revision number. So the numbers won't ever be in sync with each other without some outside help, and since anyone can check out the code, I was hoping for a solution independent of their build environment (hence svn hook ideas). So VS could have 4.1.0.9 after a few compiles but with only one commit done, svn would be up by 1.

[Squirrelington]

I gave in and just used SubWCRev.exe included with TortoiseSVN to substitute svn revision number in the AssemblyInfo.vb file and added the command in the Pre-Build event.

What this means is that anyone not using TortoiseSVN as their SVN client, and tries to compile the code will error out (or warning out, not too sure as both my developing boxes have that program).