tags:

views:

369

answers:

8

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?

+3  A: 

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.

bmargulies
I'd like to remove the human decision making process as much as possible while at the same time reducing steps. This kind of seems like the opposite from what you are saying. If there is a pattern to use git-svn (or svk, aren't they similar?), I'd be totally up for it--in fact, that was pretty much my question--how to use such a system to remove the human element from checkins.
Bill K
+1 (daily limt, T_T). I do it at work. Another possible solution (which also would reduce the number of steps) is wiping out the svn from the process completely.
Pavel Shved
The value of git is that you get a local branch. You can edit to your heart's content, and nothing you do -- nothing, will commit those changes back to the original repo.
bmargulies
A: 

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.

Pekka
+2  A: 

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).

Matt Sheppard
I'd love to be able to do this, but it would involve changes in the build. These guys are too busy as is without refactoring to support the fact that I can't remember not to check in config files.
Bill K
+7  A: 

What client do you use?

TortoiseSVN has a nifty feature that takes advantage of the changelist feature built into SVN. If you right click on a modified folder and choose "Check for Modifications," you can right-click on any of the modified files in that dialog and choose "Add to Changelist -> ignore-on-commit." From then on, whenever you perform a commit Tortoise makes sure not to add those files to the commit. See "Excluding Items from the Commit List" on this page.

If you're not using tortoise, you could set up a similar changelist manually.

Nick Meyer
This seems like a good solution but I thought that the changelist was checked in as part of the parent directory's metadata. This would mean that it would be ignored for everyone (which would be very bad). Am I wrong and the changelist is local?
Bill K
"Am I wrong and the changelist is local?" Yep. With SVN it's just a tool for you to group your local changes into categories with file granularity. It's not checked in. (I use that "ignore-on-commit" one, too, and was about to suggest the same.)
sbi
Great then! This seems ALMOST perfect--I'm doing it actually and it doesn't give me that option when I'm trying not to get it to check in a new file or directory. Is there another trick? (I could add those to SVN-IGNORE I think but that could, in theory, confuse the customer because that IS checked in.)
Bill K
As a (Partial) response to my own question in the previous comment, you can do an add first, then put the add in the changelist.
Bill K
+1  A: 

When I have a situation like this, I add the files that I do not want to check in to a change set labelled "DO NOT CHECK IN". My SVN client (SmartSVN, although Tortoise does also suuprt this) can then be set to ignore that change set, meaning that I don't accidentally check in those changes.

The only downside to this is when you have made changes to files in the change set that you do actually want to check in - you then have to manually remember to check them in.

adrianbanks
+1  A: 

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.

A: 

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.

Nick
A: 

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.

Maha
Yes, I always review the diffs as well. And yet I've checked in these stupid files TWICE. I'm just trying to fix the apparently broken part in the process (me)
Bill K