If you’re using Subversion in a corporate environment you might need to rely on path based authentication to revoke users’ read or write access to parts of a repository. Unfortunately the feature is not documented very well and there are a couple of specifics you should be aware of in advance to prevent unpleasant surprises later. I decided to describe two of them that I recently stumbled upon.

1. Path based permissions are stored completely separate from the repository and Subversion operations are not aware of them apart from the authentication itself before the operation starts. This behavior has important implications when moving branches around the repository: the permissions are not moved along with the branches but stay associated with the original location instead. You need to keep this in mind when you have a fixed path to a branch which is frequently replaced, e.g. a release candidate branch. If you set permissions to it they will stick with that path even when you archive the current release candidate branch to another location and put a new branch from trunk in its place. The permissions will now be granted to the new release candidate branch and not the old one that you have moved away. This might even be the desired behavior in your case, just be sure you know about it.
2. When moving branches around the repository their history from before the move stays associated with its original location. To view it, the user needs read permissions for that path as well even when invoking the log from the new location. When applying this to the previous example, it means that to view the complete history of the release candidate branch the user needs read permissions to trunk, otherwise he will only see the part of the history that happened after the move without being even warned that some part of the history is not visible to him.

The most important advice that I can give you when using path based authentication is to always test the settings before you start using them in production environment. I suggest you assign permissions only to groups so that you can easily have a test user which you can put in different groups to test the experience any user in this group is going to have.

Last week I was configuring the build server to compile its first Visual C++ 2010 project. I took the approach of using MsBuild on the project file (.vcxproj) as I am already doing it with the .NET projects. This worked just fine on my development machine with Visual Studio 2010 installed. It soon turned out not to be as easy as I expected it to be. The build failed as follows:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(297,5): 
warning MSB8003: Could not find WindowsSDKDir variable from the registry. 
TargetFrameworkVersion or PlatformToolset may be set to an invalid version number.

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(57,5): 
error MSB6006: "CL.exe" exited with code -1073741515.

My first thought was that there were some files missing since there was no Visual Studio installed on the build machine. Running the build command in a regular command prompt resulted in the same error after an additional message box popped up:

This was to be expected. Even on my development machine it is necessary to start the build from the Visual Studio Command Prompt for it to work. Its replacement on the build machine is Windows SDK 7.1 Command Prompt, part of Microsoft Windows SDK for Windows 7 and .NET Framework 4. From this command prompt the build worked flawlessly on the build machine as well. It seems we’re getting closer to the source of the problem… The command prompt is initialized by first calling SetEnv.cmd from the Windows SDK installation (by default in C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin) to set the required environment variables. By doing the same in the build script before calling MsBuild should do the trick for the continuous integration server as well.

Well, here lied the real problem. To simplify CruiseControl.net project configuration the build scripts are written in NAnt. Calling a batch script from NAnt is not a problem of course, there is the exec task for doing that, but any changes to the environment variables are preserved only for the duration of this task. This means we haven’t achieved anything by calling SetEnv.cmd before the msbuild task since any changes made by it are lost. The only way to make this work is by creating another batch script which calls both SetEnv.cmd and MSBuild immediately after it:

call "C:\Program Files\Microsoft SDKs\Windows\v7.1\bin\Setenv.cmd" /Release /x86
msbuild myproj.vcxproj /verbosity:minimal

It’s not ideal but it’s the only way I could make it work. Fortunately this batch script shouldn’t be changing much since everything else is configured inside the project file. I’d still prefer a solution which would allow calling MsBuild directly from NAnt though.