I've been entirely negligent about my Blogging lately, and for that I apologize. It's a sad but almost unavoidable tradeoff that, as the amount of things we're doing increases, the amount of time available to talk about them decreases, but that's a poor excuse.
If you've read my previous posts, you know that my daily work touches on a lot of areas relating to Team Foundation's Version Control features (aka "Hatteras") -- merging, shelving, file difference, conflict resolution, and security among others. I've been a busy bee lately because, as these features all start to really work -- and work together -- we get to both see our vision for the product realized, AND (of course) we get to see lots of wacky edge cases and integration points where things aren't quite working right (yet).
But this is also when software development tends to be the most rewarding and energizing. Seeing what was one just a set of ideas and designs starting to actually exist is really cool. The fact that we're "dogfooding" our own products multiplies that -- as Jason said, we used shelving to move some pending changes between us, and complete the checkin. No hassling with file shares or a potentially obnoxious email attachment, just shelve on his end, unshelve on my end, use diff to inspect his changes, and check in. I won't say whether or I had to fix any bugs in his code first...
A big part of my security-related work in November and December revolved around creating/updating/analyzing Threat Models of our product. For those of you not familiar with Threat Modeling, it's a process (as I see it) designed to make security planning/analysis as much of a science (rather than an art) as possible. The place to start learning more about it (including linkage to a nifty tool we use to streamline the process) is here: http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx
This is a critical part of our security groundwork for Team System. The Team Foundation Server is a very different piece of software compared to anything you'd find in previous versions of Visual Studio. On the flip side, other version control systems out there are often exposed to the public internet and/or anonymous access, even though many of them are not designed to be nor intended by their vendors to be so openly accessible. So it will probably come as no surprise that we're taking threats against the server in general, and the version control repository in particular, very seriously. For many of our potential customers out there, the source code they'll store in TFS is one of the company's most valuable assets; preventing illicit copying and/or modification of that code is therefore something we have to get right.