After reading Breaking Themes in 2008.5 upgrade by Chris Shawn, I had an epiphany when I started to think about how I had setup the CS SDK in my TFS store. You will be able to do this with any of the major commercial source control applications (i.e. TFS, ClearCase, CVS, etc), it won't work with VSS, and I'm not sure about SVN as it is the most screwy source control application that I have ever used.
In TFS I have a CS SDK root branch, a base branch which incorporates additions/changes that I have made to the SDK that is a direct branch from the root, and then a separate branch for each individual site that is branched from the base branch. The epiphany that occurred to me is that you can have branches within branches and even change the name of the folder that is being branched.
The last release of CS contains only one theme, Hawaii. If I were to create a branch of the Hawaii theme folder from the base branch to one of the site branches with a different name (i.e. MyTheme), then that site would contain 2 copies of the Hawaii theme named Hawaii and MyTheme. I could then customize MyTheme to meet my needs. The next time that the Hawaii theme is updated I could propagate the changes down the merge tree to MyTheme and merge them in, which would save me a hell of a lot of time.
Using the merge capabilities of a well written source control application is a million times easier than using WinDiff, WinMerge or Beyond Compare to make these changes. I can't believe that I had never considered this before, but if it wasn't for Chris Shawn's post, it may have taken me even longer.
P.S. I know that this is going to put a HUGE smile on Dave Burke's face, but only after he hits himself in the head a few times. 
From a user POV, CS2008.5 is just a bunch of bug fixes with the addition of a new application type, Wikis. But, this is a major step for developers. Here is a cursory list of the changes:
-
The SDK has been converted to Visual Studio 2008, but it appears that Telligent has not installed the latest service pack as the project files now store the Visual Studio build number.
-
The projects all target the 2.0 .NET Framework, but they are also using some of the compiler changes that were made available with the release of the 3.5 .NET Framework.
-
This means that it will not compile under Visual Studio 2005.
-
Some small, but rather significant, additions were made to the compiler that do not work under Visual Studio 2005; however, they do work when used at the command line.
-
Almost all of the projects have been renamed and the data projects have also been moved.
-
The SDK is no longer 1 solution for all. The search, mail gateways, and OpenId projects are now in separate solutions.
-
There are hundreds of compiler warning messages, which means that this was a rushed release as they didn't have time to clean them up.
-
Portions of the SDK have been marked obsolete, while others skipped the entire obsoletion process and are just gone. The CSContext object is a perfect example of the later as CSContect.Current.UserID has been removed and will very definitely break many 3rd party addons.
-
The Upgrader is not included in the SDK and hasn't been included in previous versions, but it should be. So, you will need to download the upgrader sperarately as it is the only safe way to upgrade a database.
When I upgraded to CS2007.1 back in December of 2007 I also switched over to Team Foundation Server (TFS) for Application Lifecyle Management (ALM). There were some hiccups during the initial conversion from VSS to TFS which included some loss of history (nothing new for VSS users), but it is so much faster and nicer to use that it more than made up. With the way that branching works, I have created several branches that are rooted from the CS SDK. I have a base branch from the SDK that has all of the additions/fixes that I have made. Then each web site has its own branch from this base.
When a new SDK is released, I upgrade the root and make sure that the history is preserved, which can be rather complicated. Once this is done, I merge the root down to the base which is nothing more than just SWEET! From there its a one-by-one merge from the base to each web site, which again is SWEET! Web sites can be based off of any version of the CS SDK and if I work on something for one web site that I'd like to become a part of the base I can do a merge up from the web site to base, which I'm sure you know is SWEET!
I'll probably write another post on the CS2008.5 SDK once I've used it more and have learned about its issues. For now, enjoy the changes...