Modifying File Before Subversion Commit

Question

I am using TortoiseSVN for Windows and want to figure out if I can set up some sort of macro to modify one of the files in the repository on a commit.

In my subversion repository I have a XML File called "Web.Config". There are a few nodes with the tag name "add" set up in that XML document which represents the "Build Number", "Build Description" and "Last Build Date" under the XML Path /Configuration/appSettings. This XML file uses the "key" attribute on the "add" node to determine which of these settings are being set.

The above mentioned nodes are being changed by hand before each commit (supposedly, but I don't always do this).

My question is: Is it possible to modify these settings in the file when I commit?

Answer 1

Maybe using svn pre-commit hooks?

The other option (the one I would prefer and use) is to place this data into your Web assembly during the build, and then you read it programmatically in your code. If you're using .NET, that is :)

1. Add a step to your build to generate a common AssemblyInfo.cs. (see [http://blog.darrenstokes.com/2007/12/17/ease-versioning-multiple-assemblies-by-splitting-up-assemblyinfo/])[1]
2. "Add as Link" this file to each of your projects

3. When you need this information, you can get it from Reflection, example:

   System.Diagnostics.FileVersionInfo version = System.Diagnostics.FileVersionInfo.GetVersionInfo
   (System.Reflection.Assembly.GetExecutingAssembly ().Location);

   Console.Out.WriteLine ("MyApplication v{0} by Me", version.FileVersion);

Answer 2

You can probably use pre-commit hook script. Pre-commit hooks let you execute scripts right before the server commits your changes. A good article about setting up a pre-commit hook script is here

Answer 3

Perhaps you could figure out a different system which does not require modifying files like that.

Also, I suspect you have non-source, non-dependency deployables committed to source control. I would include only source code for your projects as well as third-party assemblies that your projects reference in source control. I would ignore your projects' \bin and \obj directories.

Everyone should be able to check out the latest (or any version, really) from source control, setup external factors for their environment (create a database, set permissions, etc), execute the projects' build scripts, and have a fully functioning application.

But keeping the latest .dll's or .msi's in source-control directly is not necessary to having a fully-functioning project and might not be such a good idea.

Answer 4

Consider using subwcrev.exe to inject the build(revision) number into your web.config after the commit. This is how it's usually done in my experience (instead of doing it prior to commit) - just add subwcrev as a build step, a post-build step or part of your "publishing" step.

As I remarked in a comment above, I'm not so sure using a pre-commit hook is a good idea for this, as it would mean that your local files is instantly out-of-date the moment you commit it.