Joe Field

If your SourceSafe working folders are broken...

This happens to me a lot and it's easy to fix.  The symptom is that SourceSafe suddenly decides, with the aid of Visual Studio, that the working folders for a project or a whole project tree are not the ones you want.

Close SourceSafe on your client machine.  Also close Visual Studio.  Then on your SourceSafe server find the users/<yourname>/ss.ini file.  At the end of the file are the details of your working folders, a series of lines that look like this:

[$/CITest]
Dir (JFIELD) = D:\Projects\CITest

Delete the ones you don't like and save the file.

Share and Pin in Visual SourceSafe

I've found it useful from time to time to share and pin in SourceSafe when creating branches so thought I'd write it up here. The idea is that you share a labelled version, creating a new project based on that label. Each file in the project is pinned to a specific version. The advantage of this is that you need to explicitly branch each file that you intend to modify. And this in turn means that you have an easy indicator (the pinned icon) that a file has not been branched. This makes merging much easier, which can be no bad thing.

Stage 1: Share and Pin. Select the project you want to share and view its history (Tools -> Show History). Select a label. Click on the share button and select the node you want as the parent of the copied project. Don't check the "branch after share" checkbox. You will be prompted to input a name for the new project. Also select the "recursive" option This creates a new project in SourceSafe with all the files pinned to the labelled version. Do a recursive get of the new project from SourceSafe - don't use the "Open From Source Control" Visual Studio menu option.

Stage 2: Branch Solution. Branch the .sln and.vsscc files by using the Branch command from the SourceSafe menu. Then check them out.

Stage 3: Change Source Control Bindings. A nasty one this. Sometimes I manually edit the new .sln file to make the bindings point to the correct path, or if I'm feeling less gung ho I open the new solution in Visual Studio and use the "Change Source Control" menu option to change the bindings. Be aware that this can seriously damage your SourceSafe working directories. See my next post for how to fix this.

Stage 4: Working with the new project. The new files are pinned in SourceSafe - a useful visual indicator, so they need to be manually branched using the SourceSafe GUI before you can check them out with Visual Studio. Visual Studio will tell you that the checkout failed if you attempt to check out a pinned file. Select the file in SourceSafe that you need to branch and use the "Branch" command from the "SourceSafe" menu.

Stage 5: Merging changes in the branch back into the main project. Use the unpinned files as a visual indicator to help with identification of modified files. If you're feeling cautious (as I normally am) perform a manual merge using your favourite compare tool. If you want to live really dangerously, select the file in the main project and choose "Merge Branches" from the "SourceSafe" menu. Sometimes you'll see the dodgy visual merge tool, sometimes you'll receive no feedback at all!

Array Comparison in NUnit v2.2

Ran into this today. Was looking at some code written by Antony Marcano and noticed something which, greatly simplified, would amount to this:

[Test]
public void Test()
{
 object[] a1 = new object[] {"First", "Second", "Third"};
 object[] a2 = new object[] {"First", "Second", "Third"};
 Assert.AreEqual(a1, a2);
}

This test was passing. Surely this should fail. But it turns out that NUnit v2.2 changes the reference comparison semantics for arrays. From the docs:

Starting with version 2.2, special provision is also made for comparing arrays. Two arrays will be treated as equal by Assert.AreEqual if they are the same length and each of the corresponding elements is equal.

Character Set Shenanigans

For various reasons I've been working a lot at understanding character sets recently. There's a wealth of knowledge out there, not least Joel's excellent introductory article.

I also found Jon's resources very useful. And excellent character set tables here. And Ultra Edit text editor of course - which shows you Hex for Unicode, UTF8, 1252 etc.

Interesting things (for me, living in Western Europe) were:

• Typing Alt + 243 on the numeric keypad will input the character "¾". This is because it selects the code from the IBM 850 code page.
• But... typing Alt + 0243 on the numeric keypad will input the character "ó". This time the code is selected from the Western European 1252 character set.
• The Euro symbol goes walkies a bit - in ISO8859-1 (Latin 1) it wasn't present. It's in ISO8859-15 at 164 decimal. But in 1252 it's at 128 decimal. And its Unicode code point is 0x20AC.
• ISO8859-1 occupies the first 256 code positions (and ASCII the first 128 positions) of the UCS.
• Latin 1 and 1252 are identical from 160 to 255.

I could go on but someone might get sleepy.

Cruise Control .NET v0.9

At last! Cruise Control .NET from Scratch for version 0.9 is here. Now updated for NAnt 0.85 and NUnit 2.2. The previous one for version 0.7 is here.

I'm looking forward to getting into this version with a large system - multiple projects - multiple build servers - fantastic!