Friday, 21 October 2011

Source control for an assortment of development machines

Connection strings

For a long time, we have dealt with an assortment of SQL server releases across developers machines. Suppose we have a hibernate config file for a DotNet project. Developer 1 might have the advanced search facilities installed
    <property name="hibernate.connection.connection_string"> Server=.\SQLEXPAPR;Database=project1Db; Uid=user;Pwd=password</property>
while Developer 2 might have a different version of SQLServer 
<property name="hibernate.connection.connection_string"> Server=.\SQLEXPRESS;Database=project1Db; Uid=user;Pwd=password</property>

By convention,  we keep any config sections for an application or a test suite in a separate file such as hibernate.config.xml. Instead of dealing with the constant conficts as each developer checks in their own .config file, we check in a .config.xml.example file, which each developer edits with their own setup.

Theoretically, there could be a change which affects the whole system. However in practice we find that its sufficient to keep the web.config or app.config universal, and the variable bits for the different config sections separate.  And to talk to each other if we do change anything!


Compilation Options and Testing Tools

We all have slightly different testing tools installed (e.g. Nunit, JustCode), which we use before checking in and making changes available to the Continous Integration package, currently CruiseControl. Some of the tools need setting up in the project properties. Because this is done rarely, we just edit the Project properties by hand e.g. a unit test project might have the Debug section, StartExternalProject set to c:\CommonLibrary\Third Party Tools\NUnit\nunit.exe. This isn't a problem for source control, because the individual changes are stored in the .csproj.user or .vbproj.user file, and we simply exclude them from the checkin process.

32 and 64 bit

As we move from 32 bit operating systems to 64 bit, we find we need slight variations in the project properties to cope with different versions of tools. The Compile tabs on the project Property form is the key one. An early attempt had us scratching our skulls when we did a Build/Clean, because there were different versions of the output path for different platforms, so we still picked up incompatible verions of the code.

The trick is to use the Configuration Manager to allow a build specifically for x86. (If you need to put a new project platform, you should be careful of the tick box setting, 'create new solution platforms'.) Then check the Advanced Compile Options and Build Output Path for each platform as relevant.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">

This needs to be done for both platforms (x86, x64)  and for both Debug and Release.


To watch out for:
If your tests use relative paths, you'll need to set up your Build Output Path with the same depth e.g. bin\x86\debug and bin\any\debug.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.