We're working on improving our SharePoint integration for the Orcas release of TFS, as you may have heard/read by now.
I've been pretty busy lately on the setup-, admin-, and ops-related aspects of this work, and I thought you might like to hear some of the details. The usual disclaimer applies - this is my view on where things are right now; a lot can change between now and release.
The changes fall into several somewhat distinct improvements:
I'll add a few more details for each of these, but it will quickly get boring to those uninterested in a given feature, so I'll try to keep it short. I have one question I'll save for the end, as well.
Support for WSS 3.0
There isn't much more to this than the obvious. The setup-related details are a little interesting though. For a 'clean' Orcas install, you can elect to let us install ALL of WSS 3.0 for you - hopefully that's exciting for those of you who like TFS but don't really care about WSS's details (beyond that it's there and it works). We'll install the required prerequisite (WinFx 3.0/3.5), install WSS 3.0 itself, and configure it in a way that we can use. Note that if you choose this option, we'll still put WSS 3.0 on the TFS Application Tier, and use the SQL server used for the data tier (single- or dual-server configuration).
WSS on another machine
Dan Kershaw published a whitepaper describing how to move WSS "off the box" for Whidbey (Visual Studio 2005). We're making this a good bit easier for Orcas.
Note that in either case, the 'new' WSS instance can be WSS 3.0 or 2.0.
Agnostic to WSS configuration
This is the part that might be "boring" to a lot of you. But, if your organization has an existing WSS deployment that you want TFS to use, this will hopefully be good news to you. While we had good reasons for being picky about how WSS 2.0 was configured before, there's been a lot of requests to relax those restrictions along with the changes above. So, starting with Orcas, you should be able to give us a WSS instance that you've configured yourself. We won't require the WSS databases to have a particular name or location. We won't require the app pool to have a certain name. We still have a few requirements, of course:
There may be other details, but hopefully that illustrates what we're changing.
Now, for my question: How many folks out there anticipate that they'll still be using WSS 2.0, given the option to move to WSS 3.0? I'm sure there will be some (their org just won't be able to upgrade to 3.0 yet, and they'll want to use the org's WSS deployment rather than continue having TFS use its own 'private' WSS instance), but I'm curious if the 2.0 set is "a few" or "a lot".
A related question, of course, is "how many of you care about this kind of detail?" If a lot of you could care less how TFS handles its WSS needs, that's also good data.
Suddenly I see...