Holding a file against multiple branches in subversion

Question

I'm working on a project with multiple branches with some other developers. In my daily routine I often have to dart between branches for testing purposes and as I have a local copy of our database I tend to have a web.config file that I never check in as it has my database connection string plus some of my preferred settings.

I noticed some additional files building up around my web.config file (e.g. Web.config.r63), I'm guessing these are like revision files? Eventually my working folder corrupted and I had to re-download the source to another working folder to get back to work.

Is holding back a file in this manner and constantly moving between branches causing subversion problems? Is there a better way to do what I'm trying to achieve (Keep my local settings without having to commit them to the other developers)?

Answer 1

The cleanest way would probably be to create an own project holding the configuration/utility methods that are common to the other projects, and add it as a dependency to the main projects in question. Thus, the configuration file gains its own version tracking.

Answer 2

By "darting between branches" I assume that you mean "switching". And you say that you never check in web.config, which implies that web.config was at one point added to SVN. The web.config.r63 and other .r* files are likely popping up because your web.config is different between branches, and you're ending up with conflicts. What I find strange is that when I get these files, I also "lose" the file in question until I resolve the conflict... and when I resolve the conflict, SVN, removes the .r* files for me. Perhaps by "corrupted" you mean that the file is actually changed to contain the contents of the two revisions in conflict.

You're better off taking web.config out of your projects.

Answer 3

I noticed some additional files building up around my web.config file (e.g. Web.config.r63), I'm guessing these are like revision files? Eventually my working folder corrupted and I had to re-download the source to another working folder to get back to work.

This sounds like there were conflicts. This would happen if someone else modified the lines in the file containing your local changes.

However, conflicts create very visible messages when updating, and are easily seen at svn st. They need to be solved explicitly, but it doesn't sound like your case would be too hard. Not resolving them would result in not being able to commit from that working copy.

If my guess is right, you should have a good look at the [SVN Book}(http://svnbook.red-bean.com/) and read a few chapters about branching, merging, switching and conflict resolving. This shouldn't be more than what one can read on a rainy Sunday afternoon and should give you a better understanding about what SVN is actually doing.

Answer 4

One approach might be to check in web.config.template and to ignore web.config, which is individual for every developer. You won't be facing conflicts by adopting this pattern.