"The Source Control Experience"

I've encountered a lot of puzzling and disappointing issues while using source control recently, and while I can't fully explain all of the problems I've encountered (seriously - there are inexplicable problems), I can share what I collectively dub "The Source Control Experience."

The fundamental problem with source control is that it isn't transparent enough. It tries to be, but obviously fails. Almost every operation developers perform on a daily basis becomes more complex in a source-controlled environment. This brings up one of my most-often-asked questions - "Does anyone actually use this?" (and the corollary - "How can it be this bad if people actually use this?").

The best recent example is migrating from a Visual Studio 2003 solution to a Visual Studio 2005 solution. As if that procedure weren't complicated enough on its own, enter source control (I can hear support representatives cringing when the customer says "by the way, it's in source control").

For my company and many others, the most common thing we want to do is to take a source-controlled Visual Studio 2003 solution (which contains a mixture of libraries, web projects, and setup projects) and send it through a process that results in a Visual Studio 2005 solution that contains the same projects, still functions (bonus), and is still under source control with history preserved.

It turns out that this exact scenario, which I still think must be the most common use case in the development world (excluding HappyExampleville, which may be a larger portion of the development world than I thought), is totally impossible.

After taking a moment to reflect on the five-odd years of development it took to arrive at the intersection of most-desired and impossible, let's explore why it's impossible. The most basic reason is that web projects are explicitly removed from source control during a conversion. Attempts to add it to source control in the same location it used to be in is a total disaster (do not do this). That's pretty much the end of the game right there. I ran into other problems (none of my setup projects converted properly) that I'm somewhat confident I could have found a way around had I actually tried. Since the game was over after the web project issue, I didn't even try.

SourceGear, the makers of what I feel is the highest-quality source control product available at the moment, attempted to come up with a procedure to convert to a solution to Visual Studio 2005 without losing history. They weren't able to.

The Microsoft-recommended procedure of "take it out of source control, copy it somewhere, convert, then re-add" should have provided warning. Warning maybe not of poor conversion capabilities, but warning that they don't think their users are interested in using source control, or, if they are using source control, they don't mind blowing away their history completely. By the way, have you ever tried to completely remove something from source control? Visual Studio suddenly becomes the Oracle ("Some time ago, this solution or one of its ancient ancestors used to have or know about source control bindings. Visual Studio does not know what to do, so it will silently remap some of your working folders to confuse you in the future.").

The fact that the community isn't in a giant uproar about this makes me wonder, again, if anyone actually uses source control in an actual environment to do actual work.

One small think I'd like to add is about the new Visual Studio 2005 source control API. This was supposed to be the silver bullet that saved source control. It was supposed to allow renaming, moving, deletion, and it was supposed to have much more coarse-grained communication to improve performance over WANs. It was supposed to fix every problem everyone ever complained about in source control support boards. Well, it didn't.

I have folders that check in perfectly using the standalone Vault client, but never succeed when using Visual Studio. When another developer deletes some files from a solution, my Visual Studio is smart enough to know they're gone, but not smart enough to know they were deleted (they show up in pending checkins as "Files to add" until I do a Get Latest). It also constants wants to check in PDB files, and then fails when it attempts to, and then decides it doesn't want to check them in anymore after I do a get latest (actually, my bin directory has two PDB files in source control, and the rest of the files aren't - consistent).

The most amusing (if gaping holes in software functionality can be called that) thing about the way Visual Studio 2005 handles source control is what it chooses to put in transactions and what it chooses to leave out. All checkins go in a "pending checkin" queue that gets committed as a transaction at some later time. Well, deletions don't go in that list, they happen immediately! This makes for fantastic broken builds, and leads me again to my question: How can anyone actually have used this for any period of time and thought that it worked well? Does anyone actually use this to do real work?

Anyone who uses any sort of automated daily build (CruiseControl, etc.) would have noticed this problem immediately. This leads me to believe that no, nobody does actually use this to do real work. Our software development practices are being driven exclusively by residents of HappyExampleville, and this is hugely disappointing.