Visual SourceSafe Setup

Question

Hi All,

Currently our .net project 3.5 is spread on three separate servers of presentation , business logic and state servers. Please recommend on how to setup this project under VSS 6.0 taking into consideration that we have multiple projects on dotnet and we have a series of development team working on them. Currently we have them as Project 1:

>Business Object Layer
>WebService
>Proxy
>Web

Project 2:

>Business Object Layer
>Proxy
>Web

One of the challenges faced being the actual implementation will happen across three servers but currently we are storing them under one root and this is causing us undue headache.

Answer 1

I would lay out the developer's working directories like so:

c:\src\
    solutions\
        *.sln files with references to the project files
    project1\
        project1.csproj
        *.cs
    project2\
        project2.csproj
        *.cs
    ...

That is: one project (*.csproj) per directory, no nested directory structure. All solution files in a separate directory. (optionally put the solution files in the root (src) directory).

The developers open the solution files for the part of the system they're working on.

The folder structure on the VSS server should be exactly the same.

On the production servers, I would just pull everything down to all servers (If you build on the servers, that is. If you do not build on the servers, I would create deployment scripts that build the correct solution on the developer machines, then copies everything from bin\Debug|Release to the correct location).

On a side note, I would recommend using another source control system, for instance subversion. VSS is not easy to work with and tends to get in your way, IMO.

Answer 2

Since you are unable to use any non-Microsoft tools have you looked at using Team Foundation Server (for least the version control component) rather than VSS? From my experience TFS is a decent source control system. With TFS you have the nicer edit-merge functionality rather than exclusive checkout that makes development by more than one person much nicer. In addition the branching and merging is much better in TFS than VSS.

There is a free workgroup license for TFS that gives you up to 5 named users, after 5 users or if you want Active Directory authentication/authorization you must use the standard edition. Depending on your particular MS Partner benefit level your company may already have a license for TFS.

In addition, all clients need to have a CAL (and Team Explorer installed). From my understanding of MS Licensing it is not required that everyone who will be accessing the TFS server have a Team SKU of Visual Studio and that you can continue to use VS Pro and purchase a TFS CAL (which comes with Team Explorer). I have implemented this exact solution at a previous employer.

In TFS I would set up your solution like this (I have only shown the Trunk as fully expanded and a (partial) feature spike branch) :

$/Project1/
   Branches/
       /Spike1/
           BusinessObject/
               BusinessObject.sln
               BusinessObjectProject1/
               BusinessObjectProject2/
           WebService/
               WebService.sln
               WebServiceProject1/
               WebServiceProject2/
           <etc>
   Tags/
   Trunk/
       BusinessObject/
           BusinessObject.sln
           BusinessObjectProject1/
           BusinessObjectProject2/
       WebService/
           WebService.sln
           WebServiceProject1/
           WebServiceProject2/
       Proxy/
           Proxy.sln
           ProxyProject1/
           ProxyProject2/
       Web/
           Web.sln
           WebProject1/
           WebProject2/
$/Project2/
   Branches/
   Tags/
   Trunk/
       BusinessObject/
           BusinessObject.sln
           BusinessObjectProject1/
           BusinessObjectProject2/
       Proxy/
           Proxy.sln
           ProxyProject1/
           ProxyProject2/
       Web/
           Web.sln
           WebProject1/
           WebProject2/

The Branches folder is so that you can easily implement standard branching and merging especially since TFS only allows branch/merge operations to take place between a branch and it's direct ancestor and direct descendant. The idea is that most day to day development takes place in Trunk and when you need to temporarily isolate changes for work on a major feature or spike you take a branch from Trunk into Branches which you can then merge back into Trunk when you are ready to integrate (as well as being able to continue to merge ongoing changes from Trunk into your feature branch).

The Tags folder is so that you can both branch to a tag when you are ready to take a snapshot of a particular version of your code as well as using this folder for build and deployment. For build and deploy you create a branch from Trunk to /Tags/Test and from /Tags/Test to /Tags/Production and then you merge your changes from /Trunk to /Tags/Test when you are ready to promote your changes to the test environment. You can have either a continuous integration build running on /Tags/Test or an on demand build that will perform a build from that branch and copy the necessary artifacts to the appropriate locations. You can have similar functionality on the /Tags/Production branch so that as you merge changes from Test up to Production you continue to have an automatic build and deployment.

In addition to better source control, with TFS you also gain things like an OK CI build server (using Team Build and building on either the TFS box or a dedicated build server), work item tracking (which is quite good and nicely customizable) and a decent project portal using the SharePoint integration with TFS. All of this additional functionality is also very compelling and I recommend looking around at some of the other great TFS content available on the web for more details.