Forced Source Control Checkouts in SSIS BIDS Solution

I learned today that the new Visual Studio/SSIS "Business Intelligence Development Studio" (BIDS) has some trouble when multiple people are working on multiple SSIS Packages within the same Solution.

Imagine this scenario:

Myself and another developer on the same team are working on Package A and Package B, which are part of the same SSIS Solution. I have Package A checked out and my counterpart is working on Package B--sometimes he has it checked out, and sometimes not (like when he's gone home for the night).

Regardless of whether he has the package checked out or not, I still need to be able to *look* at his package without checking it out. This is normal behavior any programmer would expect in an IDE. For one thing, there's no need to check it out, because I'm not planning on changing anything, but more importantly, his package is in a half-done state, and I want to keep my local copy, which is a stable version from a few revs back. (We're using VSS so developers don't have private check-in areas for incomplete work.)

The problem is that BIDS keeps forcing a checkout when I open the other package (the one my teammate is working on). It's happened once when I drilled into a data flow task, and another time when I was just looking at the variables window. Suddenly a window pops up announcing that a checkout is taking place, and before I know it I've got a mess on my hands, with multiple modal error dialogs popping up, caused in part because BIDS is now loading a version of the package that contains incomplete work and references to dtsconfig file entries that I don't have locally. I imagine some other series of errors would occur if my teammate *did* have it checked out and the attempt to write to the package was foiled.

I think it has something to do with the background validation that's going on; some part of the SSIS validation process realizes that it needs to write to the package, so Visual Studio obliges by checking out the file.

Has anyone else run into this issue? Any suggestions? Please comment below. If I find a workaround I'll update this post.

Update: I tried an experiment to use the File->Source Control->Change Source Control menu to disconnect my BIDS session from source control (uncheck the checkboxes in the grid in the dialog box that comes up). It seems to have worked OK for my purposes. After disconnection from source control, I drilled into a data flow in the read only package (which is what seems to reliably trigger this forced checkout) and sure enough it tried to check out. A few confirmation dialogs in a row popped up, and I kept indicating to not checkout/cancel/ignore.

Finally after several "Cancel" and "OK" button clicks, a dialog box with this text came up:

The connectors could not be refreshed for the following paths:
   Path 'InsertPath' (ID: 16993): The checkout was canceled by the user.
  Path 'UpdatePath' (ID: 16987): The checkout was canceled by the user.

"InsertPath" and "UpdatePath" happen to be two names for branches in a Conditional Split transform in this data flow. So this tells maybe tells us something about what background process is causing this. The good news is that after the flurry of dialogs I was able to proceed with my poking around in the data flow in the read only package. I imagine I'll have to go through this again if I go back and forth between the control of flow and the data flow. Ugh.

Changing topics only slightly, I'm coming more and more to the opinion that the ubiquitous modality of BIDS for SSIS is a fatal flaw that makes the tool almost unusable for projects of significant size. Because of all the modality there is just no way to get any kind of productivity traction, even after getting over the steep learning curve. And the keyboard-mouse switching is just killing my right arm. On my second major SSIS package I pushed a *lot* more code down to normal .NET DLLs to minimize the development in SSIS.

Dan