How can I muddle around in subversion transactions from a hook script?

I've read all the warnings. I want to see for myself what will blow up if in a pre-commit hook script, I change the files that are being committed.

It would be a good thing if the client is ignorant of this for my particular purposes. People are checking in system passwords that we want to keep out of the repository. I've got a perl script that regexes through changed files, and if it sees a password it vomits up a warning along with filename and line number.

So now they have to dig back into the file (it's probably not even open), delete the password, save it, and re-commit. Trouble is, then they have to re-open the file, put the password back in to continue working. It's annoying. If Subversion intercepted the file, scrubbed the password, and secretly committed that... it seems like that's the ideal circumstance. No one works around the pre-commit script, svn doesn't save sensitive passwords, and people aren't constantly removing passwords that they'll just have to put back in after committing (which would probably discourage commits, the last thing we want to do).

I'm language agnostic here. If you know how to do it in php or C or m68k assembler, I'd like to see an ex开发者_开发知识库ample. Doesn't have to be perl. If the Subversion police show up to question you, you're welcome to pin it all on me.

---

Not really an answer to your question, but I would keep the approach you already have - to deny the commit. On the client side though, if the person working with the code wants to easy her life, she can use some scripts on the client side. Maybe applying some previously generated diffs/patches before and after a commit. Some other options are given in with this SO question: client side pre-commit hooks in subversion