Branch/Tag quirk in Subversion

I wasted 15 minutes of my life today to find out that when creating a branch in Subversion, it will always create one and only one new directory.

I was attempting to help a colleague who was trying to create a branch from his working copy. Important note: the repository did not already have a branches folder, which we wanted to create.

I walked him through the steps, and when it came time to enter the new branch's URL, I had him enter something similar to //repositoryRoot/branches/myNewBranchName.

SVN returned a cryptic error message: Path not present. Well, yeah. You're supposed to create the path.

So, I tried creating the folders in the repository. Now, SVN says that the path already exists. ARGH! I know that. I just created them!

My colleague finally figured out that SVN needs to create exactly one directory when creating a branch. Going back to the repo, we kept only the branches folder, entered the path, and voila! It worked.

So, when creating a branch in Subversion, remember that it must create one and only one directory.

Store Server-specific Settings in External Config File

I just learned that the appSettings node in an ASP.NET web.config file can reference an external configuration file. This is extremely handy for managing values that change depending on whether the site’s on development, staging, or production servers.

Take this example: you have a simple contact form that sends an email. On the live, production site, you want that email to go to someone in customer service. However, in a development or testing environment, you probably want that email to go to a developer or QA tester.

Here’s how to set it up:

In the web.config:

   1: <appSettings>

   2:     <add key="CSEmail" value="customer.service@somecompany.com"/>

   3: </appSettings>

Then in the appSettings.config file:

   1: <appSettings>

   2:     <add key="CSEmail" value="developer@testdomain.com"/>

   3: </appSettings>

ASP.NET will attempt to load the appSettings.config, with any keys overriding those in the web.config. If appSettings.config exists on the development server, it will read developer@testdomain.com as the value. If the file doesn’t exist, it will use customer.service@somecompany.com as the value.

So, in our example, we would simply not upload our appSettings.config to the production server.

Easy. Peasy. Lemon squeezy.

Tightening the Wallet

Hello, friends and family. I've returned the blog to Blogger, since, well, the web hosting I needed to keep TheLuebbes up and running isn't free.

So, here's a first little post to get this one started. I'm looking into ways to import the archive-worthy posts here, but if that doesn't work, I'll simply post them anew. Please refrain from throwing tomatoes at the admin.

Anyhoo...

Sorry for the change. Hope you still find it worth your while to subscribe to the RSS feed.