If you are developing a product and are nearing a milestone, you have the option of maintaining multiple versions of that project, at the same time. Using VSS you can use share, pin, and branch as described in the topic Share, Pin and Branch to Create Service Pack Projects (Bug Fixes). Or you can also use labels.
If your situation requires a few lightweight patches with minimal changes to the build process, labeling is the way to go. If, however, you plan on a lot of ongoing development, performing a share, pin, and branch is the way to go. For instance, you would use the label-promotion feature to freeze the source tree during a Beta, and also to make fixes to the Beta. If, however, you are working on Version 1.1 and Version 2.0 of a product at the same time, the way to go is to make each version a new project, and then share and pin all the files, branching them when needed. When 1.1 has shipped, you can label the 1.1 project, then merge changes back into Version 2.0.
Below are some scenarios using the label-promotion feature you can use as a guide.
Scenario #1 — The ideal
Develop and test your project in the drive toward Beta 1.
At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
Begin working on Beta 2.
Scenario #2 — A different existing version of a file needs to be in Beta 1
Note The label-promotion feature only works if the new database format has been turned on. Run the DDUPD.EXE utility to activate the new database format. See DDUPD for more information.
Develop and test your project in the drive toward Beta 1.
At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
Begin working on Beta 2.
If the wrong version of a file was included in the original Beta 1 label, select the file, then click Tools, Show History to display the History dialog.
Select the version of the file that should be included as part of Beta 1 and label it "Beta 1."
Get the project at Beta 1. This will get the project as it was at the date and time you labeled it "Beta 1" except that it gets the new version of file you just labeled individually as "Beta 1."
Scenario #3 — A fix of the current version of a file needs to be in Beta 1, while no other files have changed
Develop and test your project in the drive toward Beta 1.
At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
Begin working on Beta 2.
You realize that the version of the file included in the Beta 1 label (e.g., Version 4) has a bug in it that must be fixed. No other files in the project have yet changed.
Check out the file, make the change, then check it in.
Label the project "Beta 1" again. (You'll be asked to confirm that you want to remove the old label.)
Scenario #4 — A fix of the current version of a file needs to be in Beta 1, while other files HAVE been changed
Note The label-promotion feature only works if the new database format has been turned on. Run the DDUPD.EXE utility to activate the new database format. See DDUPD for more information.
Develop and test your project in the drive toward Beta 1.
At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
Begin working on Beta 2.
You realize that the version of the file included in the Beta 1 label has a bug in it that must be fixed. Unfortunately, other files in the project have been changed and the changes have been checked in.
Check out the file that needs to be fixed, make the change, then check it in, creating a new version.
Label the file "Beta 1" (the same label as you labeled the project). This promotes the new version of that file into the label "Beta 1."
Now, if you do a Get of the project at Beta 1, it will get the project as it was at the date and time you labeled it "Beta 1" except that it gets the newer version of the file you just labeled individually as "Beta 1."
Scenario #5 — An older version of a file needs to be fixed and added to Beta 1
Note The label-promotion feature only works if the new database format has been turned on. Run the DDUPD.EXE utility to activate the new database format. See DDUPD for more information.
Develop and test your project in the drive toward Beta 1.
At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
Begin working on Beta 2.
You realize that the version of the file included in the Beta 1 label has a bug in it that must be fixed. For example, the current version of the file is Version 6 and it contains changes made on the road to Beta 2 you don't want included in Beta 1.
Check out the file (Version 6).
Get Version 4, overwriting the local copy of Version 6.
Make the changes necessary to fix the bug for Beta 1, then check in the file. This makes a Version 7 of the file (Version 4 plus the fix you've just made, minus all the changes in Versions 5 and 6).
Label Version 7 of the file "Beta 1." This promotes Version 7 of the file into the label "Beta 1."
Now, if you do a Get of the project at Beta 1, it will get the project as it was at the date and time you labeled it "Beta 1" except that it gets Version 7 of the file (the one you just labeled individually).
To continue work toward Beta 2, recovering changes made in Versions 5 and 6, check out the file again (i.e., check out Version 7).
Get Version 6.
Overwrite the local copy of Version 7, or merge the two file versions (this ensures the local copy becomes Version 6 plus the fix you made in Version 7 for Beta 1).
Make any other changes if you want, then check in the file. This creates version 8. You can now resume work toward Beta 2.