0

To start with some background, I am a member of a small team developing an ASP.NET application. In addition to us, there are 2 other teams working on it, all from different countries. Source code is hosted on a shared SVN server but there is no central testing environment. Each developer runs the app on their own machine and data services are set up per team.

Unfortunately our SVN workflow has some gaps in it: annoyances arise when there is time for an SVN update.

It is mainly because each developer and team have slightly different environments in terms of disk directory structure and configuration (both IIS and app itself). Hence conflicts in configuration files and elsewhere that in essence are not conflicts at all - for runtime configuration (XML) and in *.suo.

How should we handle this if our objective is to keep checkout, app setup and update as painless as possible?

One option would obviously be master copies. Another one establishing uniformity in developer environments and keeping it. But what about a third alternative?

Saul
  • 17,973
  • 8
  • 64
  • 88

4 Answers4

2

One thing to do is to not put the .suo files into SVN, there's no reason to do that.

Andreas Brinck
  • 51,293
  • 14
  • 84
  • 114
  • There are also **application configuration files** that contain different data on different environments. Our main issue is about having a standard and painless solution for synchronizing machine-dependent configuration files without bothering each other too much. One option is master copies but is there another way? – Saul Apr 13 '12 at 08:43
1

For IIS configuration there should be no argument - uniform environment across the build team.

For app.config files and the like, I tend to keep them in a separate "cfg" directory in the root of the project and use pre-build events to copy in the relevant ones I need depending on the project and environment I'm working on.

You could have a separate build task to copy in user-specific config into your output directory. Add a new directory in your root project called "user.config or something, and leave it empty. Then configure your project build to check this for entries and copy them to the output directory. This is easy to do, and then each dev can have their own config without affecting the master copies. Just make sure you have an ignore pattern on that folder so you don't commit user-specific configuration. If you have svnadmin access to your source code repo, you could set a hook to prevent it from ever happening.

Also set ignore patterns on your root directory (recursively) for .suo, .user, _Resharper or any other extensions you think are pertinent. There are some So questions already on exactly this topic:

Best general SVN Ignore Pattern?

Community
  • 1
  • 1
Mel Padden
  • 983
  • 1
  • 9
  • 21
1

Ignore *.suo and *.user files in svn. It is easy. After that create two types of config files in subversion. Development and Server, if in use add Test also. See below example.

ConnectionStringDevelopment.config
ConnectionStringServer.config

AppSettingsDevelopment.config
AppSettingsServer.config

Server files would contain server information. Development files is not contained in svn and ignored there. Every new developer will start by copying server files and making changes according to his environment.

Look following example site http://code.google.com/p/karkas/source/browse/trunk/Karkas.Ornek/WebSite/web.config

following lines are interest.

<appSettings configSource="appSettingsDevelopment.config"/>
<connectionStrings configSource="ConnectionStringsDevelopment.config" />

ConfigSource can be used almost everywhere in web.config therefore you will be able to change every config to every developer. Only make use of following naming convention. ignore *Development.config in subversion. This way no developer config will be added to subversion.

Atilla Ozgur
  • 14,339
  • 3
  • 49
  • 69
0

Its not a perfect solution (and should only be used if there are not many of those special files), but what I do is to add fake files for each case, and switch the real file locally to it. In detail: I have a file foo that creates the problem. I also create foo_1 and foo_2 and then locally switch foo to foo_1 (I use tortoisesvn, so I cant really give you the command line to do that). Then I am working on foo on my machine, but actually commit to foo_1. Other parties could then switch to foo_2...

(I admit this is basically a variant of the master-file approach you suggested yourself; but if there are not many actual changes to those files this at least reduces the numer of conflicts you have to think about)

FrankB
  • 349
  • 4
  • 10