Version Control

The primary function of Visual SourceSafe is to keep track of database file and project histories. A history consists of all versions of a file or project, from the initial version to the current version in the database. You can view the history of a file or project, and retrieve any version of the item from the database.

You can access the history of a file or project using the Show History command on the Visual SourceSafe Tools menu. For a file, this command opens a History Options dialog box, in which you can make file history settings as needed for your team environment. For a project, Show History opens a Project History Options dialog box, which lets you make project history settings. For more information, see How to: View History.

Reverse Delta Technology for File Version Control

Visual SourceSafe uses a reverse delta technology for controlling file versions. The reverse delta technology saves only the latest version of a file as a full version. Other versions are saved as version deltas, reflecting only the differences between versions. This method of versioning ensures that all versions of a file are available, but uses a minimum of disk space.

Version Control by Internal Version Number

Visual SourceSafe automatically assigns an internal version number for each version of a file or project. This number is always a whole number that increases as the file or project accumulates history. As a database user, you have no control over internal version numbers.

Version Control by Date/Time Stamp

A date/time stamp is one of the markers that the NTFS file system uses to control file and project versions. Visual SourceSafe uses a standard Windows date/time stamp to mark a new version of a file or project in the database any time you modify, label, check in, or check out the item.

Visual SourceSafe supports date/time stamps in both the 12-hour format (with "a" or "p" suffix) and the 24-hour format. You can customize your database to apply date/time stamps. For more information, see How to: Set the Time Zone for Your Database.

Version Control by Label

Visual SourceSafe allows you to define a label for a file or project version. A label is a free-form string of up to 31 characters, for example, "2.01b" or "Final Beta". Using labels for version control allows you to maintain multiple versions of a file or project at the same time. You will probably find that, at a project level, you prefer user-defined labels for version tracking, instead of the internal version numbers described in "Version Control by Date/Time Stamp." However, it is rare to label individual files.

Note   If your team requires some lightweight patches with minimal changes to the build process, it is a good idea to use labeling and label promotion for version control. See How to: Maintain Multiple Versions of a Project.

The following table compares internal version numbers and labels as version control mechanisms in a Visual SourceSafe database.

• Assigned automatically by Visual SourceSafe.
  Assigned by user, using Label command.

• Always a numeric value.
  Any combination of letters, numbers, symbols, and spaces up to 31 characters.

• Always increases to next whole number.
  Anything user assigns.

• Increases every time an action that affects storage is taken on a file or project, such as adding, checking in, or branching.
  Assigned when user feels that a significant milestone has been reached.

• Displayed in history, paths, links, share, and file properties dialog boxes and in file panes of Visual SourceSafe client programs.
  Displayed in history dialog boxes as a user-supplied string. Indicated by a label icon next to the project name instead of a version number.

• Simply identifies a new version, but does not create a version.
  Creates a new version of the file or project. The label is associated with the new version.

• Cannot be edited or changed by user.
  Can be edited in the History Details dialog box.

Use of Pins in Version Control

Visual SourceSafe defines a pin as a marker that designates a specific version of a file as the version that is part of a project. The pin is represented by a pushpin icon, and is added through the Pin command in the History of <name> dialog box. For more information, see How to: Pin a Version.

You can pin any file, but you should do this only when you are not planning to change the marked file. Pinning is most useful when applied to shared files.

Note   When you pin a shared file, you cannot make changes to it until you unpin it using the Unpin command from the History of <name> dialog box.

If you share a pinned version of a file, the projects sharing the file cannot change it. However, if you share an unpinned file, and then pin it in one project, other projects can still change and update the file.

Let's examine an example of using pins for version control. One developer has prepared a spell checker program. The first time the version of the program is stable, the developer uses pins to mark particular versions of the program code files. He then notifies a developer of a grammar checker program that uses the spell checker code that a good version is available. The second developer can share and branch the code and use the pinned file versions as the basis for his spell checking components of the grammar checker program. He only obtains the last known good code files for the spell checker, unless the first programmer unpins his file versions at some point.

See Also

Tasks

How to: Maintain Multiple Versions of a Project
How to: Pin a Version
How to: Set the Time Zone for Your Database
How to: View History

Reference

History of <name> Dialog Box (Explorer and Plug-in)
History Details Dialog Box (Explorer and Plug-in)
History Options Dialog Box (Explorer and Plug-in)
Project History Options Dialog Box (Explorer and Plug-in)