The SOS cache file and local file status

[corey]

The SourceOffSite Client tracks information about the state of files on the local machine that are under source control in text files that are often referred to as "cache files", "server cache files", or "SOS files". The files are named "databaseX.sos", where X is a number for each database served by a given SOS Server. The cache files are text files and can be read with a text editor, but they should *not* be modified manually.

In SOS 4.X, the cache files are located in the Documents and Settings folder at the path:

\Documents and Settings\<username>\Application Data\SourceGear\SOS\servers\<servername>\

(In SOS 3.X, the cache files were located in a subfolder of the SOS installation directory)

Within each <servername> subfolder, there will be a list of databaseX.sos files and a file named index.sos. The index.sos file is a text file that links each database served by the server to a given databaseX.sos file.

Within each cache file, the SOS clients keeps track of the following information:

1. The project hierarchy of the VSS database
2. The working directory set for each project
3. The name of every file for each visited project
4. The VSS version number of the version of the file that exists on the client machine
5. The time at which the file was fetched by SOS

The SOS Client uses the VSS version number of the local file (item 4 above) to determine if a file is out of date with the latest version in the VSS database. If the version number locally matches the version of the file in the VSS database, then status is current (or blank in the GUI). If the version number of the local file is less than the version of the file in the VSS database, then status goes to Old. And if the version of the local file is greater than the version in the VSS database (which could happen after a rollback, for instance) then statues goes to More Recent.

The SOS Client determines the local version number of each file on the client machine in one of two ways:

1. By fetching the file itself (i.e. performing a Get Latest Version)
2. By refreshing the file list with checksums enabled (if the checksums of the local and remote versions match, then the files are determined to be the same version). Refreshing the file list with checksums enabled is useful when setting a working directory to a location where files under source control already exist and you do not want SOS to refetch them all.

The SOS Client uses the time at which the file was fetched (item 5 above) to determine if a file is Edited (modified and checked out) or Renegade (modified by not checked out). If the local modification time of the file does not match the timestamp of the file when it was fetched, then SOS marks the file Edited (or Renegade).

If files under source control exist in a working directory but SOS does not know the local version number of the file (because SOS did not fetch the file itself, a refresh file list with checksums was not performed, or was performed but the checksums did not match) then the file is marked Unknown.