Source Control, GotDotNet, VS.NET, and Dream Job #3

  • Article

Tone Engel reports that, "Joined the FlexWiki GotDotNet group last night for source code access which is provided through a custom source code control provider that integrates with Visual Studio."*

I am an avid FlexWiki and GotDotNet user/contributor and just recently joined the GotDotNet development team here at Microsoft. Prior to joining my new team last week, I worked on the MSDN Communities & Personalization Team for a couple of months before being plucked from the comfortable nest of my new team by another hungry manager :-). Prior to MSDN, I spent roughly four years contributing to development of:

  • Visual Studio .NET 2002 (v1)
  • Source control integration for the Visual Studio IDE (called "vscore" internally).
  • Visual SourceSafe 6.0a,b,c,d,e and 8.0 (called SourceSafe internally;-)
  • A secret project that got canceled just as we were about to roll out the Beta. Big bummer.
  • For most of last year, I worked feverishly on Hatteras, which is the killer new source control component of the upcoming Visual Studio Team Foundation family. Hatteras is the next big thing in version control.

My new job is to determine how we can improve GotDotNet to better meet the needs of the developer community and ad hoc collaborative development projects like FlexWiki. I'll be working closely with Betsy Aoki. In the short term, I think that's going to mean providing better support and documentation. In the long term, I believe that we must maintain the spirit, community, and well-rounded feature set that makes GotDotNet such a great place to go for sweet ideas, useful kludges for dev tools, words of advice, jumpstarter code samples and full-on starter kits, and to meet and collaborate with other folks who share our passion for code and our time/domain-specific interests. We also have to beef up our back end services and improve some usability issues which, in addition to source/version control, is my specialty.

[Tone Engel again] "I'm certain Whidbey will address this hole in Visual Studio's current support for 3rd party source control integration so I don't think it makes much sense to take this project any further. It's silly that Visual Studio doesn't auto detect the source control provider from a solution file and switch it for you on the fly."

Whidbey does "address this hole" and yes, it is silly. I fought the good fight to include this functionality in Visual Studio 2003 (aka Everett) and lost. However, I successfully convinced my team, thanks to your many and vociferous complaints, to include automatic source control provider switching in Visual Studio 2005, Whidbey. Woohoo!!!  I've been using it without a hitch for months. For those of you who don't want to or cannot install the VS2005 Beta (like, um, you're working on production code), there are quite a few SCC switching tools for Visual Studio 2002 and 2003 around, in addition to the one that Tone points to in his post. I think I've mentioned most of them in a series of blog posts...

BTW, it is absolutely awesome to witness the development of tools like this out on GotDotNet. Perhaps we should consider opening up some of the GDN codebase for community development, like Slashdot. What do you think?

Other SCC Provider Switching Utilities for Visual Studio .NET 2002 and 2003

How To: Switch Source Control Providers in VS.NET
SCC Plug-in Switcher for Visual Studio
How To: Switch Source Control Providers in VS.NET (Redux)
How To: Switch Source Control Providers in VS.NET (ReduxRedux)

+++++++++++++
*To better meet the needs of the FlexWiki virtual development team, DavidOrn and a few other pivotal members migrated the codebase and mainline development over to SourceForge in October of last year. FTR, I supported that move despite mixed feelings. I wonder if the creation of the position I now fill was somehow precipitated by that event. Hmmm {wry grin}.