How do I avoid checking in local changes to the SV

Question

I have to make local changes to my project files in order to get it to run in a different environment. Twice now I accidentally checked those changes in (and messed up everyone else's running environment).

There are probably a lot of better ways to set up our build, but since I work as a consultant on an established project I can't really change how the customer works.

I've tried setting up a second branch in the same repository (which backfired, duplicating the entire tree in the root of their repository--I won't be messing around with that again).

Tried setting up a second repository of my own and checking in JUST those files to the new repository. This got really messy as well and basically didn't work.

I'm considering SVK--it looks like it MIGHT be able to help, but I can't quite figure out a pattern that would work.

I think I even posted here and didn't get a good answer, but that was before I was seriously considering SVK--I figured with that new parameter there might be a better solution.

I realize I could track the changes I WANT to check in and then just check those in, but that's a human dependent and buggy procedure that, to date, has failed me twice (because I'm a buggy human).

Any suggestions on just how to do this?

Answer 1

I've had good luck using svn switch to keep personalized files from stomping on others' configurations. Given a normal trunk/branches/tags layout, make yourself a folder in branches containing your personalized configuration file. Then

svn switch URL-to-personalized-config URL-to-standard-config

This will cause edits to the config file to be saved off in your branch and not to the trunk. You get versioned edits to your config file, and can't easily mess up the trunk file.

Answer 2

Solution depends on how many changes you're talking about. I work with .net websites so for most sites I'd have a different config file for each environment. e.g:

web.deploy.config
web.dev.config

These would all be under source control. Then copy the one of these files to web.config on the server it's running on (leaving this file out of source control). Works for me.

Answer 3

I can't think of any uncomplicated way to do this. Is there no way to dynamically check (within your files/scripts) which environment you are in, and make the settings accordingly? I used to do that in PHP with a simple directory check (if working directory equals C:\projects... then set path to ... )

Another option could be a pre-commit hook that excludes or reverts the changed files but in the former case, you would not be up to date, and in the latter, you'd have to make the changes again... hmmm.

Answer 4

You could use git-svn. You get a local repo in which you can have local history, and several opportunities to consider your sins before inflicting them on the svn repo.

Answer 5

I generally try to arrange things so the standard files SVN checks out can be overridden by a separate file which is svn:ignore-ed

For example, I have a bash script which starts a Jetty web server using a config file. Normally it is jetty.xml, but if jetty-local.xml is present on the filesystem, that's used instead.

(Of course, the obvious problem there is that when jetty.xml gets some updates, they won't be merged into jetty-local.xml, but that may be less of a problem than what you're already facing.)

In a PHP project I used to work on, this was taken even further with two separate code trees - /system where all the system classes were checked out, and /local which mirrored it, but was empty unless a local class were added, in which case it was loaded in preference. That may well be getting too fancy for its own good.

If it's configuration files which you own that are the problem, another solution I've used is to arrange to read them hierarchically (i.e. read in global.cfg.default, then overwrite with any settings in global.cfg.local).

Answer 6

I always review the diffs of all my files before a commit, that way I can make sure I'm not leaving some debug code in and it gives me a second chance to review my changes.

If you're running on a Unix/Linux machine with tksvn w/ tkdiff installed, you can check out a nice graphical representation of each diff one by one this with this command:

for FILE in `svn status | grep -v ? | sed -n "s/^[MA]//p"`; do tkdiff $FILE; done

Another smart way to double-check yourself is to check out a fresh copy of the repository and try to build and run it--that way you can catch if you forgot to add a file or broke something obvious.