5

Help me do some damage! I'm tired of just a half-dozen Google hits that tell me never to do this. Let's muck things up real good! I'm pretty sure that I can get ahold of the actual files in db/transactions, so how can I screw these up in interesting ways? I've looked at SVN::Delta, but I can't even figure out what it's supposed to be doing (letting someone make pretty graphs of changes to a repository? sending coded messages to the CIA?).

I really don't care to hear more reasons why not to do this. I work in an environment with 40 or 50 other people who use subversion. And while we're coding, we need some passwords in web.config files, in DataSource.groovy files, you name it. And just refusing the commit because we left them in is as annoying as hell. We have to save the files with the passwords manually deleted (and we have to open up those files, it's not like they're necessarily open), then once we're done committing we have to put them back just to continue to work? This is a good idea I suppose if you just want to bitchslap people every time they commit until they develop a Pavlovian reflex to never commit anything. And why? Because computers aren't supposed to automate tasks? Because the software client won't know that the pre-commit hook didn't actually save the version still on the developer's machine?

I'm fairly language agnostic here. Show me an example of how to do what you're never supposed to do... which file do I edit from pre-commit? How do I interpret the gobbledygook after the DELTA # # # line? Are there any libraries that will help with that? Let's have some fun!

PS Seriously, no one's created a "bad-ideas" tag? WTF.

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

1 Answers1

4

It is your build process that is flawed, not Subversion. If you must not commit passwords, do something like the following:

1 - Web.config files should not be committed. Instead, commit files like Web.config.dev or Web.config.qa.
2 - Have your build script rename the appropriate .config file to Web.config, and then do token replacement so that the proper passwords are inserted. This info can come from another file that is also not commited that says what environment you are in (so it knows which .config file to use), and what the passwords are.

D'Arcy Rittich
  • 167,292
  • 40
  • 290
  • 283
  • That's really nice... telling me that we shouldn't do version control on files. I guess if one is lost or corrupted in production (happened just a month ago), then we can ask them to pull tape backups and get it working again in a couple days. Client-side sounds really nice, there are only several dozen developers... and when the new computers are rolled out in a couple months, we can install it on several dozen systems again just for fun! – John O Sep 28 '11 at 15:42
  • 2
    @John I don't think you are following me. The files you don't commit are generated automatically by your build script. The only file that is not created by checkout or or build script is the password file, which is explicitly not committed as a requirement from you. Similarily, your deploy script creates the web.config for you. – D'Arcy Rittich Sep 28 '11 at 15:53
  • 2
    @JohnO: No, he's telling you to version control the files, except without the passwords inserted, and then have an automated process insert the password. Sort of like how you version control a `.c` file, but not the generated `.o`. – derobert Sep 28 '11 at 15:53
  • We use about four different IDEs at this point, not including the various VS versions for legacy apps. It also is more than just scripting/configuration/deployment for those, it means changing habits of over 50 people, some of whom will be receptives, others not. There are a few people here that just got their 20 year service pins. Then, if we manage to do all that, the next hardware rollout will blow all that away, and it's one more thing they have to manually install on the machine to become productive again. What happens if someone is tinkering, and puts the data connection in another file? – John O Sep 28 '11 at 16:17
  • 2
    @John It sounds like you have developer, process, and sys (or desktop) admin issues. Those are beyond the scope of this question, but are all addressable. IMO, by messing around with SVN internals, you are creating another problem, not solving any. – D'Arcy Rittich Sep 28 '11 at 16:30
  • Problems are testing/production passwords accidentally being committed to svn, and the inevitable workarounds that people will take if svn is just a club to beat them with whenever they try to commit. People will commit less often (bad) or stuff passwords into files we don't check (worse) or in ways that will circumvent the regexes that find them (worst). I can't brainwash all of them en mass, we can't change culture, we can't hire all new people who will do things right. If all of this can be fixed with a simple technical solution, why not? If subversion makes that solution impossible... ugh. – John O Sep 28 '11 at 16:40