svn server: how to manipulate existing revision

Question

I have a svn server (VisualSVN Server Manager)

On this server, we want to automatically obfuscate the incoming binary files.

I wrote a post-commit.exe for this.

I can see which files are affected with "svnlook" command.

But the problem is that I cannot directly manipulate affected files from with post-commit.exe.

For this, I have to checkout to another svn (client) folder and commit new changes.

But since the post-commit.exe has not finished its job yet, another client cannot update at that time and it will fall into deadlock.

For this reason, I have to make these changes on the server without using a client.

I think I can do this with "svnfsfs" or "svnadmin". But I don't know how to do this. Could you help me with this?

Thanks in advance.

Answer 1

Instead of performing the task on the server-side, you better consider obfuscating your binaries on the client-side, before you commit. Do not commit transactions or add new revisions with hook scripts. If you use TortoiseSVN, maybe the client-side hook scripts could help.

1. The post-commit hook runs when a new revision has already been committed. Even if you manage to modify the data in post-commit and create a new revision in the repository, you will end up with two revisions - a first one with the original content and a second one with modified content.

2. You could modify the commit transaction with a pre-commit hook script, but this is a bad practice. Per SVNBook:

   While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors, shortcomings, or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As a bonus, your users will learn the value of careful, compliance-minded work habits.