0

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 example. Doesn't have to be perl. If the Subversion police show up to question you, you're welcome to pin it all on me.

John O
  • 4,863
  • 8
  • 45
  • 78

1 Answers1

0

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

Community
  • 1
  • 1
Sunny Milenov
  • 21,990
  • 6
  • 80
  • 106
  • If I just refuse the commit, this is annoying to them. If it's annoying, they will eventually just alter the various strings enough that my regex doesn't recognize them. It's not like I can come up with some bullet proof regex. So instead of technology helping prevent them from checking in passwords, then it just becomes an obstacle ready to bitchsmack them when they're in a hurry. It makes them delete passwords in the local copy of their files, and they might lose them (if undo screws up) and have to go through the rigamarole of getting it issued again from the security team. – John O Sep 26 '11 at 17:01