SVN - How do I intercept and alter or add files on pre-commit?

Question

First of all I'm not sure this is even possible, however I need to know how it can be done and if not why not?

I want to create a C# application that runs at the appropriate time during the commit process of a subversion repository (pre-commit I believe) that will then add another file to be committed.

For example, I make changes to Program.cs, and Main.cs, but NOT AssemblyInfo.cs. I want to be able to force a change to AssemblyInfo.cs or any file for that matter.

I wrote a console application using SharpSVN that fired on post-commit, which then replaced a file, but this caused an increment in the revision number. Obviously that's not ideal.

I then found SvnLookClient within SharpSVN that runs on pre-commit and have started writing something, but hit a dead end when I realised CopyFromPath didn't mean what I expected:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

Alternatively, I will settle for doing this outside of C#, but ideally I'd like to do it in a C# console application so that I can also tell my repository server to perform other tasks like running in database scripts, etc.

Answer 1

You must not modify the transaction during a hook-script. You can either reject the commit with a message (stderr will be sent to the client), or do it in a separate commit in the post-commit.

[edit] I want to clarify why modifying transactions is a bad idea (svn-technically):

The client does not know anything about it.

Except for "OK", "FAILED" and the stderr output there is no back-channel from the server to the client during a commit.

When the client commits its changes, and the commit is reported to be successful, it marks its local file and folder status to be in sync with the repository version [xyz]. When you later change something, for instance, add the file locally, it wants to commit those changes, but then... Well, you can try to know what happens, I expect something along "checksum error" or "file already added". Depending on the type of the changes you would probably have no better chance to get a working WC than by deleting the folder and do a fresh checkout of the damaged part.

That was the technical part. Now the developer-side: First, automatically fixing changes correctly seems smart, but it will fail, due to the simple fact that if source would be pre-computable, we would not have to let it write by developers. You want your developers to do the right thing.

This works best via education: they have to know what the right thing is. Good measures to get them to know something is, additional to good old training of whatever kind, giving them feedback.

An error-message from the svn server, an automated mail after broken builds or unit-tests, results from a static source-code analysis tool, etc., can also serve as a good educational tool.

I would recommend using continues integration, and validating the source-tree there. This has the advantages that a developer will not be blocked to commit his changes after a long working day, but you still know that status of the source-tree.

And, I now just guess what you want to try to achieve: The server-side source-tree shall always be "functional". Then the problem is that even with automatic file-fixing, pre-commit unit-testing, style-checking and whatever, you, finally, still have to check whether the program actually works, by old-style system-testing. So basically, you do not really gain anything.

Technology can support processes, well thought-out tools support it so well that following processes actually helps developers saving time and making their workflow simpler. But technology usually cannot replace processes, and it cannot replace human intelligence (at least, for now). [/edit]