How to: Maintain Multiple Versions of a Project
Development of a product rarely ends at the end of a milestone. More often than not, a development team decides to continue working on the next version of the product, while some updates and changes still have to be made to the original product code base. Visual SourceSafe has a set of features, such as share, pin, and branch, that allow developers to facilitate this kind of parallel development environment. To perform minor updates to the code base of the original release, label promotion is another feature that can be used.
Normally, labeling is used when a product milestone is complete and all source code needs to be appropriately labeled. For example, if you ship Beta 1, you might want to label the project "Beta 1." After shipment, minor changes might need to be made to some of the files, while the rest of the code remains intact for the project. In this case, label promotion can help you "promote" a different version (usually the latest version) of a file to become part of the already labeled code. This technique works best when the file has not yet been modified in the next milestone.
Using Label Promotion
This section describes label promotion procedures for maintaining multiple project versions. For all these procedures, let's use a particular scenario. The milestone we are just finishing up is Beta 1, and our next milestone will be Beta 2. We will be making minimal changes to the files in Beta 1, and beginning development on Beta 2.
To use simple labeling (the ideal):
Coordinate the team in developing and testing the project in the drive toward Beta 1.
When your team is ready for Beta 2, label the original project "Beta 1." See How to: Label an Item.
Begin working on Beta 2.
To add a different existing file version to a release:
Coordinate the team in developing and testing the project in the drive toward Beta 1.
When your team is ready for Beta 2, label the original project "Beta 1." See How to: Label an Item.
If the wrong version of a file was included in the Beta 1 label, select the file, then click Show History on the Tools menu.
In the History Options dialog box, select the version of the file that should be included as part of Beta 1, and label it "Beta 1."
Now get the project at the Beta 1 label. The get operation retrieves the project as it was when you labeled it, except that it also retrieves the new version of the file that you have just labeled.
To add a fix of a current file version to a labeled project (no other files changed):
Coordinate the team in developing and testing the project in the drive toward Beta 1.
When your team is ready for Beta 2, label the original project "Beta 1." See How to: Label an Item.
You realize that the version of a file included in the Beta 1 label has a bug in it that must be fixed. No other files in the project have changed.
Check out the file, make the change to fix the bug, then check the file back in.
Relabel the development project with the Beta 1 label. Be sure to answer "Yes" when Visual SourceSafe prompts you to remove the old label.
To add a fix of a current file version to a labeled project (other files changed):
Coordinate the team in developing and testing the project in the drive toward Beta 1.
When your team is ready for Beta 2, label the original project "Beta 1." See How to: Label an Item.
You realize that the version of a file included in the version label has a bug in it that must be fixed. Other files in the project have been changed and the changes have been checked in.
Check out the file to be fixed, make the change to fix the bug, then check the file back in.
Select the file, then click Show History on the Tools menu.
In the History Options dialog box, select the version of the file that should be included in Beta 1 and label it "Beta 1." This promotes the new version of the file into the Beta 1 label.
Get the project at the original project label. The get operation retrieves the project as it was when you labeled it, except that it now retrieves the new version of the file that you have just labeled.
Using Share, Pin, and Branch
If the need for a bug fix occurs after a project has been labeled and further developed, use the following share, pin and branch procedure. It will use a minimal amount of hard drive space.
Let's use a scenario for example purposes in this procedure. We have developed the version 2.0 of a software project and are moving to version 3.0. We find out that we need an interim version 2.1 for bug fixes.
To use share, pin, and branch operations:
Coordinate the team in developing and testing the project in the drive toward the version 2.0 release.
In Visual SourceSafe Explorer, label your project "Version 2.0." See How to: Label an Item.
Begin changing files in the project for version 3.0, which will introduce new features.
When you realize that you need an interim version 2.1 for bug fixes, select the project.
On the Tools menu, click Show History.
In the Project History Options dialog box, select the Include Labels check box and click OK.
In the History of Project dialog box, select the label "Version 2.0."
Click Share.
In the Share from <name> dialog box, select the project to be the parent of the newly created project. This is usually the $/ project.
Ensure that the Branch after Share check box is not selected, and then click OK.
In the Share dialog box, give the project a new name, for example, $/Application V 2.1.
If the project has subprojects, select Recursive.
Add comments in the Comment box as needed, then click OK.
After closing the dialog box, select $/Application V 2.1. All files in this project should now be pinned.
Select only those files that need to be changed to address bug fixes, then branch the file(s). Leave pinned any files that do not need to be changed.
Later on, you can merge bug fix changes back into your version 3.0 project.
See Also
Tasks
How to: Get an Item to Your Working Folder
How to: Label an Item
How to: Merge File Versions
How to: Pin a Version
Reference
History Options Dialog Box (Explorer and Plug-in)
Project History Options Dialog Box (Explorer and Plug-in)
Share Dialog Box (Explorer and Plug-in)