Customer Question
Currently, we have created a single CompanyName.ksn solution which contains two completely unrelated Projects. Each project is being led by a different developer and yet we are opening the same solution file. This has caused conflicts, as you might expect, and yet it can t make sense to place the KSN file under source control since then only one developer can work at a time.

We have already experienced a situation where a project file has been overwritten with a much earlier version; I need, as quickly as possible, to configure our files, solutions, projects, and developers, in such a way as to ensure both maximum efficiency and security.

Response

On LAB, we only had one solution with one project. However, we had a similar scenario in our .NET development IDE where we had one solution file with multiple project files. They way we worked it was not to have the solution file checked into Source Safe. The reason for this is because the solution file contains the file location of the individual project files (as and when they are added to a project) on the local machine. Not everyone uses the same location for their solutions and projects, hence the reason for not putting the solution file into Source Safe.

The individual project files, however, were added to Source Safe and kept checked in. Whenever a new object needed to be added to a project, the project file needed to be checked out, the object added, and then both the project file and new object checked back into Source Safe. Thus, the project file must NOT be left checked out by anyone at any time and only when an additional file or object needs to be added to a project. This allows anyone wanting to add additional objects to a project to check the project file out and do so.

To setup the whole solution on a developers machine, a developer would then get the latest version of all project files, including all subfolders, objects etc., from Source Safe, create a solution file (using any name) in the .NET IDE, and then adding each of the individual project files to the solution.

We are acutely aware that we have issues in this regard and are addressing this in Black Pearl by leveraging the MS Visual Studio integration into the Microsoft Team System and VSS.

Also look at the article below which shows how a customer can easily incorporate different users and groups in development vs. production:

http://kb.k2workflow.com/articles/kb000163.aspx

Also Consider Subversion
If you re looking for an alternative source control style, look at subversion. Subversion doesn t follow the check-out, mod, check-in pattern. Instead it defaults to the copy, mod, merge pattern (it also allows the other pattern using a config option by the way)

Using the copy, mod, merge pattern, developers can have the same solution, project file, whatever open at the same time (no check-out locking), and make any changes they like. The subversion merge system then inspects the files for conflicting changes and, if none are found, merges all changes happily. If conflicts are found, developers are given the opportunity to address the conflicts, line-by-line before reattempting the merge.

http://sharptoolbox.com/tools/ankhsvn
http://en.wikipedia.org/wiki/Subversion_(software)