The Vagaries of Source Control: VSS is a Bad Sign

I jump into a new project and at last – AT LAST – they are giving me Visual Studio and a substantial body of code to work with.  I talk to the guy in charge of the code right now, and he says he’s got a copy of the source posted to a network share.  My safeties aren’t tripped by this, but they should be. In no circumstance should I ever be pulling code from anywhere that doesn’t have the word “repository” somewhere in its description.

I grab the code and it turns out there are not one but two copies of the code – the current version that is “in prod”, and the version that got developed, then cancelled, then (now) re-requested.  This is the code I need. 

Of course, it’s not exactly the code I need.  The code I need is very slightly different from this code.  I have to apply a few changes to the cancelled version. 

I load up Visual Sourcesafe.  Part of my brain is screaming the entire time, because I have seen the enemy and he is VSS.  But for a wonder this repository is reasonably well-structured.  Well, except for the IGNORE_CANT_DELETE* projects.  These are probably not good signs. ONWARDS!

Funny thing, though: I can’t find my project.  I search, and for a wonder it works, very promptly providing me with an empty result. The code isn’t in there. 

Fine, I think, I’ll put what we have in there.  I set up a structure that I like (one directory at a time, because I don’t trust VSS’s recursive commit), add the files (worrying about atomic commits all the while), and label the lot with the production version tag (knowing that a label in VSS is about as trustworthy as a hungry dog). It seems to go well. 

I check out the code just to make sure, and the project builds.  Well, sort of.  I mean, the main project builds; I’ve had the foresight to add the bin directory with the required interop and .OCX files, but I guess I forgot about the deployment project, and so that project, and hence the solution, is freaking out.

After a little file wrangling I commit the necessary binary support modules – with only a tiny shudder of self-loathing – and we’re good to go.  Right?  I mean, clearly, that’s gotta be it.


When I go to diff the files in VSS with the development code, I get a whole lot of “binary files differ”. Not helpful, VSS.  Not even a little bit helpful. 

But I’ve been here before. VSS isn’t a Unicode-friendly product; not much was for a lot of years, so it’s not something I can blame (entirely) on the product. 

I look at the properties of the files.  Here’s where things get ugly: Like a lot of teams I’ve worked on, this one is still using VSS 6, because that is what comes with Visual Basic 6, and that’s the killer app (at least in the sense that it is slowly killing me) (THIRTEEN LONG YEARS VISUAL BASIC). These products were not that forward-looking.  Unicode hadn’t really come into its own when they were released, so they don’t do much in the way of catering to different encodings.  Or end of line characters.  Or endianness.  Or anything else that you might actually care about because it introduces IMPOSSIBLE TO F*@KJS@)  FIND BUGS INTO YOUR SYSTEM


Fine, I think.  I’ll fix this manually.  I know (more or less) what Visual Studio does with these files; half of them are XML documents, so that’s easy – the encoding is right there in the xml header at the top of the file.  The other files are a little more work, but I play around with the encoding of the working and repository copies until VSS’s diff does basically what I want it to. 

Somewhere in there I learn that in some cases VSS will try really hard to get you to compare files as if both copies are UTF-8, which is kind of adorable in the same way that your girlfriend’s purse dog biting the annoying guy next door is: Sometimes it’s handy, but most of the time it’s just making things worse down the road.

I get all of my files into VSS as Unicode or UTF-8.  I think.  There’s no way to batch edit properties on repository copies, so I could conceivably have missed some in my file-by-file right clicking slog.  There’s also no way to profile the history of encoding changes on files in the repository.  Given my last SCC system was Subversion, this is mildly upsetting, but it is after all VSS, so it’s not like my expectations are being violated.

At this point it seems like I might be able to keep the time logged to commit the code to a reasonable number.  That illusion, however, falls apart once I start applying my changes.

See, here’s the thing: (if you are old enough you remember that) UCS-2 used to be a thing.  Specifically it used to be the “default meaning” of Unicode in the Microsoft world. I should have known this.  In my defense, I see ANSI/* and I ignore the second half of the pattern. 

If I had taken the time to look up MBCS, I’d have remembered that yes, Virginia (Washington?), Microsoft kind of half-assed their implementations a lot back in the day. And as a wonderful legacy of that, products like VSS have some odd ideas about how you should refer to encodings.  You would think, for example, that if you said “Unicode”, then any encoding that falls under that moniker would just work.  Not so.

Instead, you get to spend ANOTHER three hours FIXING the encodings of your repository files one by one. 

Oh, SourceSafe.  You stupid, ugly prick.