Fugato

A brief feature comparison: in mid-flight I am impertinent enough to want to diff my checked-out code to see the changes I have made.

Under (the free-of-charge and open-source) Subversion, that would have been “Sure, here you go.”

Under (the $3,000 proprietary) Team Foundation Server, it is “be thankful I’m letting you work at all. And when you get online, go download a separate utility and ask it politely to sort out which files you have changed.”

And here I was trying to break the rant habit. Dagnabbit!

Yeah, Team Foundation again.

When we started using Subversion at work (AnkhSVN in alpha and no VisualSVN yet), I managed Subversion adds and commits and updates manually using the excellent TortoiseSVN, and left Visual Studio out of it.

The downside of that was moving and renaming files. Doing it in Visual Studio left Subversion unaware of the change, and doing it in Subversion left Visual Studio unaware of the change. Either way, one of them ended up seeing one file missing, and another file popping up that they knew nothing about.

Generally I renamed in Subversion and then manually edited the .csproj project file accordingly. Not everybody is happy doing that, and if you happen to do it when Visual Studio has unsaved changes to the project file, then it gets a little messy.

So moving to Team Foundation (and hence SCM integration) should have made file renames less painful.

Indeed, renaming a file is now a single operation in Solution Explorer. But it takes a full minute.

I’m not pulling that number out of anywhere dark and unhygienic. I measured just now. 78 seconds.

78 seconds renaming a file!

Okay, two files. It’s a workflow class file with a .Designer.cs sidecar file. But still. Renaming one file took 38 seconds, measured just now.

38 seconds renaming a file!

And these are files that haven’t even been checked in yet. They’ve just been added. And it’s not auto-updating references to the class name in my solution, because there aren’t any.

It’s like that every time, even late at night when I’m alone in the building. It’s not because of load. Team Foundation is set up on a virtual machine in one of my company’s VMware container machines a dedicated monster machine with 6 CPUs and silly amounts of RAM, serving maybe 60 or so developers. Our Subversion server was a wee VMware machine also running Trac and some other stuff, and was plenty fast enough (but to be fair, it was only serving about 15 people). Our admins assure us that the machine is not overloaded. If it’s a matter of “killing it with iron,” then TF sure needs a heck of a lot of iron.

The clincher: it took me less time to do the rename manually (flipping out to Explorer, renaming in TortoiseSVN, editing the project file in a text editor, reloading the project in Visual Studio) than it now takes Visual Studio to do the rename automatically.

And, of course, Visual Studio is completely locked up during the operation, so my work gets to wait. Because, you know, background operations are just too much to ask.

OK, I feel better now. Just had to vent. Sorry.

My Visual Studio output window just now, showing output from Source Control - Team Foundation.

All files are up to date.
All files are up to date.
All files are up to date.
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Implicitly suggested course of action: reboot, followed by ignore-it-and-hope-for-the-best?

… are over, because we moved our source code to Team Foundation.

Yea, verily I say unto thee, that is a modal dialog box.

So my Visual Studio is locked up — completely — until somebody gives the server the kick it deserves.

I did try clicking cancel — but, of course, the cancel operation hangs too.

This costs thousands of dollars. Thousands! The usability is less grievous than SourceSafe (and that’s not saying much) — but the reliability, at least in my experience here, is worse. Fancy that.

I miss my Subversion.

Fishy hang.

My Visual Studio 2005 hung completely, out of the blue. Did not respond to any mouse clicks or keyboard events, though it did redraw.

I tried firing up another VS2005 to debug it, but that hung too and then closed.

So I tried firing up a VS2003 and attaching the native debugger to the hung VS2005. And the debugger crashed.

I sent the crash data to Microsoft, and tried again; same results several times, with the crashed VS2003 restarting automatically each time.

Finally closed the VS2003 manually, started a new one and attached, successfully. By this time the VS2005 window was gone, but the process was still there. Got a minidump of the hung VS2005 if anybody wants it.

(Incidentally, one of the process modules jumped out at me with the name custsat.dll … that might stand for “customer satisfaction,” which, taken in context, is a wee bit amusing.)

Detached and killed the VS2005 process and started a new one, but nothing came of that.

Finally resorted to a reboot, but the shutdown was interrupted by a VS2005 window appearing, with a modal dialog with this message:

TF30331: Team Explorer could not connect to the Team Foundation server source
used during your last session. The server may be offline or the network is unavailable.
Contact your Team Foundation Server administrator to confirm that the server is available
on the network. Use the Connect to Team Foundation Server command on the Tools menu to
reconnect to your previous server.

The server returned the following error: The operation has timed out

Figures that it was the Team Foundation server, because the same mess was going on on a co-worker’s machine at the same time.

But … the server catches a flu and the whole IDE hangs?

Closed the modal dialog and the studio window, rebooted, and started up VS2005 again.

It seems to be working now … but I don’t need this kind of aggravation. I have work to do, and I miss my VS.Net 2003 (!) and the trusty, robust, never-hanging Subversion we were using along with it.

I googled the error message and got nothing. So if this were Eclipse or NetBeans or IntelliJ (or, indeed, Subversion) hanging, I would go file a bug and attach the minidump to it and feel all warm and fuzzy about helping out. And I would cheerfully expect a new version fixing the problem. In less than two years’ time, even.

But it is a Microsoft product; I do not know of a public bug database, and I do not feel inclined to go telephone the uninvitingly-named “Professional Support Services” and stay on hold while all of their customer representatives are currently busy assisting other callers and will answer my call in the order in which it was received, and then try to convince one of them that I’m honestly not that big an idiot (a relatively small-framed one, in fact) and that there really is a problem. No thanks. So last-millennium.

That kind of prejudice — while indicating the image Microsoft still has, despite the best efforts of MSDN bloggers — begs to be proven wrong and unfair. I want it to be proven wrong and unfair. And sure enough: after a little spelunking, here is the place to submit feedback, without hanging around on the phone at all. I’ll go do that instead of whining like a crybaby.

All right, after signing in with my Passport login, and then signing up with name and email and age and all that (yet again — now, what was Passport for, again?), I spent about 20 minutes carefully describing what happened, providing exact product and add-in versions and the like, and then submitted. Kabloom:

And yes, that does repeat when I back up and retry the bug submission several times.

Ah well. I did give it a try. And I’m glad they have it. Just look forward to trying it out when it’s feeling better.

EOR