Recently a colleague emailed me for guidance on the installation of Team Server. When the next email arrived a while later with the question “Am I correct that if we want to utilize Visual SourceSafe 2005 we need to install Team System Server”, I knew I should have asked a few more questions in the first iteration of emails. At least he had the opportunity to explore Team Foundation Server, SQL, Sharepoint and Reporting Services … and in his own admission had lots of fun.
BUT, to use Visual Source Safe 2005 you do not need to install Team Foundation Server, which comes with its own Version Control engine. Both products are separate and “independent” products from each other.
Visual Source Safe (VSS) 2005 … is the new edition of the version control solution that has shipped with Visual Studio for some time. It is still file based, but requires no services from Team Foundation Server … it is a separate and completely independent solution. Sorry Matthew, I should have elaborated on this last week
Team System Version Control … Team Foundation Server is the battle ship that offers a complete software development life cycle, or at least the foundation, to the solution teams and one of its services is the Version Control engine, which is tightly integrated into the TFS and its process. Unlike VSS, it is SQL Server 2005 based and exposed by an ASMX web service. Yes, we could use it independently by accessing the web service, however, its true strength are only utilized in conjunction with TFS. There are also some peculiar differences with VSS, such as the ability to define add|delete permissions in VSS, but not in TSVC. TSVC offers shelving, which resolves my concern of where to put what in a secure way when going home, but not wanting to commit changes to the build. They also offer a good medium for once off code reviews, but are unfortunately not really suited for managed and “workflow” based code reviews as yet. Using a two branch promotion concept, for example, gives a better audit trail of changes and authorization thereof. Take a peek at “Team System Source Control” one http://www.drp.co.za/default.asp?id=technologies/content_technologies_t for one of our quick reference posters, which covers TFS.
Migrating from VSS to TSVC … the move from VSS to TFS can be done using the VSS Converted, which can perform an analysis on the VSS databases and migrate these to TFS version control.
So what about the Proxy … we all have had the pleasure or pain to work in remote locations, with version control servers on the other side of the planet, accessed via the worst possible connectivity. While 3rd party tools decreased the pain in the VSS world to some extent, you can install Team Foundation Server Proxy, which caches previously accessed source control files, either on the same server as the TFS application tier or even on a separate server. The Version Control Proxy caches both current and prior file revisions in GZip (non-deltified version) compressed format, which are sent to the Version Control Upload Handler on the server during a check in. Interestingly enough the files in a changeset are committed to the server and according to the “visible check in-process” the check-in operation completes before the delta process comes to life on the server in a background process that periodically sweeps the system looking for deltification work to do. Another important note is that the proxy is a circular cache, which means that items fall out based upon age when the size threshold is exceeded. Note that historical checkouts are not cached. For more information on the proxy, check out the screen casts on http://go.microsoft.com/fwlink/?LinkId=62788.
This post does not deliver justice to any of the products referred to herein. Make sure that you explore the products and their documentation in more detail, because all have their place in our binary yes|no, on|off environment.