Visual SourceSafe (VSS) is a client/server application which acts as a storage system for files. A file stored in a VSS server is not available via the standard file system, instead, it must be accessed through the VSS client tools - the VSS windows client, the VSS command-line tool, or else some application which integrates with or emulates these client tools.
VSS Database
A VSS Database is a single instance of a VSS server - it's the big black box into which files get placed. All commands to VSS are directed towards a particular VSS Database, and wach database maintains a SRCSAFE.INI file which contains configuration information
VSS Project
A VSS Database is organised as a tree structure, with each of the nodes of the tree being a VSS Project. Each database contains a single root project, which can branch (to a depth of 15 nodes) into sub-projects.
VSS Projects are misleadingly named; instead they should be thought of as directly analagous to filesystem directories, being unordered collections of up to 8000 files of any type. To illustrate this, note that where an application's source-code is organised into files that live in subdirectories off the main directory, these subdirectories have to be mapped onto subprojects of the application's main project directory.
Note: Don't confuse Visual Studio 'projects' with Visual Sourcesafe 'projects'. T1he latter are more like directories, or folders. In fact, if you just think Visual Sourcesafe 'folder' where the documentation says Visual Sourcesafe 'project', it will be easier to follow.
Working Folder
Because the files stored in VSS are not directly exposed as files, development work on these files takes place on local copies, which are first checked out of VSS, changed, then checked in again. While a file is checked out of VSS, it is can be locked to other developers, preventing file overwriting. VSS also retains historical information about a file's changes, so it is possible to extract and use old versions of a file, or roll back unsuccessful changes.
The folder in which a user manipulates his local copy of VSS project files is known as his 'working folder'. Each user will often have a distinct, local working folder for each VSS project, the details of which are held by the VSS client in its SS.INI file.
Each working folder also gets populated with a VSSVER.SCC file, which contains version information about the files in that folder. This allows VSS quickly to determine whether or not local files are synchronised with those stored in the VSS database.
Note: If it is possible that the source-code for your application may contain hard-coded file paths, it is important that developers' working folders are at the same location. One way of doing this is to require each application's working folder to be at the root of a particular drive
Building and Deployment
Let's consider the situation in which two developers, UserA and UserB have to cooperatively develop application are coming completely fresh to VSS, and neither uses an IDE to create the application.
In this scenario we shall assume that each developer has a development machine, and that there is a development server which both of them can access. This gives us the following three computers: DevelopmentUserA; DevelopmentUserB; DevelopmentServer
The first thing that needs to be done is for a VSS database to be installed on DevelopmentServer, and the VSS client tools to be installed on the two development machines. It's useful to know that the installation of VSS on DevelopmentServer sets up a network share to the installation directory, and the VSS client tools are available for users to install from there (this has the additional benefit that the client tools are set up with the DevelopmentServer database as the default).
Next, the VSS database has to be set up with appropriate users. VSS handles its own authentication, rather than integrating with Windows authentication (though file access is still subject to NTFS permissions, of course), so it is necessary to set up individual accounts in VSS for the two users.
Adding and Configuring a Database
As the database administrator, you must configure the server and the database(s) for your team after installation of Visual SourceSafe. The first step is to add one or more databases to the environment.
Once you have set up the database(s), you will need to configure the server for the types of access needed by the database users. For example, access via the SourceSafe Internet plug-in for Visual Studio requires the Internet service to be running on the server machine.
When you have provided all the services necessary for the database users, it is time to secure the database(s) and limit user access. This will protect the databases from unauthorized use and help to ensure data integrity.
How to: Add New Database
Visual SourceSafe allows you to add a database to your team environment by either creating a new empty database or using an existing database. You can add a database using the Add SourceSafe Database wizard in either Visual SourceSafe Explorer or Visual SourceSafe Administrator. You may also add an existing database to the list of available databases with the Add SourceSafe Database wizard.
To add a database using the Add SourceSafe Database wizard
1. If using Visual SourceSafe Administrator, on the File menu, click New Database. If you prefer to use Visual SourceSafe Explorer, on the File menu, click Open SourceSafe Database and then click Add. Either method opens the Add SourceSafe Database wizard.
2. The first step of the wizard is just a welcome page. Click Next when you are ready.
3. The next step of the wizard allows you to enter a location, or browse for one. Click Next when finished.
4. Now the wizard allows you to specify a friendly name to help you remember the database connection. Click Next to proceed.
5. Visual SourceSafe offers two work styles, Lock-Modify-Unlock and Copy-Modify-Merge. Select the work style for your team environment and click Next.
6. The last step of the wizard summarizes the file share settings for your database. Check these settings and click Back if you need to make changes.
7. When you are finished with your database settings, return to the final step of the wizard and click Finish. The wizard creates the database as you have requested.
8. Go to the database path that you have specified to make sure that the database is available as expected. It will have a Srcsafe.ini file in the installed Data directory for Visual SourceSafe.
How to: give Privileges to Users
Next, the VSS database has to be set up with appropriate users. VSS handles its own authentication, rather than integrating with Windows authentication (though file access is still subject to NTFS permissions, of course), so it is necessary to set up individual accounts in VSS for the two users.
To give database access privileges to users using Visual SourceSafe Administrator
1. If using Visual SourceSafe Administrator, on the User menu, click add User.
2. Then add user window will appear, enter user name and sourcesafe password, then click OK.
3. Now we can configured and give access to server source safe database for added user to use visual source safe from his machine.
How to: Configure Database in the client machine
To connect an exciting database using the SourceSafe Database wizard
1. If using Visual SourceSafe Administrator, on the File menu, click Open SourceSafe Database. If you prefer to use Visual SourceSafe Explorer, on the File menu, click Open SourceSafe Database and then click Add. Either method opens the Add SourceSafe Database wizard.
2. The first step of the wizard is just a welcome page. Click Next when you are ready.
3. In next step of the wizard need to select connect to an exciting database. Click on Next.
4. Here select connect to an exciting database a location or browse (Go to the server database path that you have specified select Srcsafe.ini file). Click Next when finished.
5. Now the wizard allows you to specify a friendly name to help you remember the database connection. Click Next to proceed.
6. The final step of the wizard will appear and click Finish. The wizard creates the database as you have requested.
Getting vs Checking Out
If you 'Get' a file / project (which you do using the client tools by right-clicking on the item and selecting 'Get Latest Version'), a read-only copy is placed into your working folder. Changes you make to this file cannot be subsequently uploaded to the VSS database.
On the other hand, when you 'Check out' a file / project (which you do analagously to 'getting' it), a writable copy is placed into your working folder. By default, this locks the file to other users, so that while they may 'Get' a copy of the file they cannot themselves check it out. Notice that when you check out (and check in), you have the option to add a comment. This is to help developers keep track of the file changes.
When either of these options is being applied to a project, the procedure can be applied recursively, so that it is applied to subprojects of the chosen project.
Checking In
When you've finished making changes to a checked-out file / project, then you can check it in again, which writes the file changes to the VSS database. This procedure is also effected in the client tools using a right-click menu.
By checking project files out and in using VSS, developers can avoid the situation in which one overwrites the changes made by another.
Multiple Checkouts
By default, if you check out a file then no other user can check it out until you've checked it back in: the file becomes locked to changes by anyone other than you. But the VSS administrator may enable 'multiple checkouts', which (fairly obviously) allows multiple users simultaneously to check out files.
So, what happens when UserA and UserB each checks out a file to his local working folder, each updates it independently, and then each tries in turn to check it back in? What needs to be avoided here, obviously, is UserA's changes being overwritten by UserB's check-in. What VSS tries to do is to merge each user's changes into the master copy. This is easiest if users have made small changes to different parts of the file. However, if users have each changed the same part of the file then merging is not possible, so VSS rejects UserB's check-in attempt, with appropriate information about the problem, and requires him to resolve the conflict.
