On Source Control and Flow

While working on a new WCF front-end for some legacy software today, I wanted to go look at how another team setup the WIX file for their service. So, I fired up a second copy of Visual Studio and began fighting with AccuBridge. Here’s the sequence of events:

  • Launch Visual Studio
  • Open solution from Start Page
  • Wait...
  • Wait some more...
  • Wait a little while longer...
  • Accept changes that AccuBridge found in the repository
  • Wait...
  • Realize I opened the wrong solution
  • Try to open correct solution
  • No response, just a throbbing AccuRev icon in my status bar

image

  • Wait some more...
  • Try to close Visual Studio

image

  • Wait a little while longer...
  • Finally, AccuBridge finishes futzing around and allows me to open the correct solution
  • Wait...
  • Wait some more...
  • Wait a little while longer...
  • Accept changes that AccuBridge found in the repository
  • Open the WXS file and find the line of code I need

Without AccuBridge, this process would have taken 2 minutes, tops – even with accidentally opening the wrong solution. With AccuBridge, this process took a rather frustrating 10 minutes. I almost forgot what it was I was looking for.

Some might argue that I should have just popped over to Windows Explorer and viewed the file in Notepad. Others might argue that I should turn off AccuRev integration in Visual Studio. But, neither of those solutions is optimal: one loses syntax highlighting, the other loses source control integration.

It seems to me that the proper solution would be for my source control provider to wait for an explicit command before running off to check the repository for updates. It also seems to me that a plug-in should allow the parent application to close, regardless of what it is trying to do when the end user asks to close the application.

Why these things don’t work this way, I do not know. One thing I do know – it would do wonders for my flow.