When you pin a version of a file,
you mark that version of the file as the version
that you want to use when you check out that file
for a particular project.
Pinning therefore enables you
to specify an earlier version of a file for use
in the current project. This is helpful in a scenario
such as the following:
- Version 1.0 is the current production version
of the product. Version 1.0 files have been
labeled in the project. They are modules A,
B, C, and D.
- Version 2.0 is in development. It uses newer
versions of modules A, B, C, and D. Beta testing
has begun, and these files have been labeled
with the version 2.0 stamp.
- In the meantime, version 1.0 is still in
production and there is a need to distribute
version 1.1 that will fix problems in module
C of version 1.0.
- You want to be able to make changes to the
bad module C of version 1.0. At the same time,
you need to move forward with development of
module C of version 2.0.
You can use a combination of
sharing, pinning, and branching to fulfill your
needs (see Step by Step 2.9).
STEP BY STEP
2.9 Using Share-Pin-Branch to Create a "Service Pack" Version While Concurrently
Working on a Newer Version
1. Share the original version
1.0 project files.
- Select the project's folder in Visual
SourceSafe Explorer.
- Choose Tools, Show History from the Visual
SourceSafe menu to bring up the Project History
Options dialog box.
- Make sure that the Include Labels option
is checked and click the OK button. This will
display the History of Project dialog box.
- In the History of Project dialog box, select
the version labeled 1.0 (see Figure 2.21).
FIGURE 2.21 - Selecting an older, labeled
version of a project in the History of Project
dialog box.
- Click the Share button to display the Share
From dialog box.
- Make sure that the Visual SourceSafe root
is selected in the Share From dialog box's
Projects tree (see Figure 2.22), and click
the OK button to display the Share dialog
box.
FIGURE 2.22 - Selecting the appropriate
parent project in the Share From dialog box
(usually, the root).
- In the Share dialog box, give the new project
an appropriate name, such as "Version
1.1" (see Figure 2.23), and click OK
on the Share dialog box and Close on the History
dialog box.
FIGURE 2.23 - Naming the new maintenance
project in the Share From dialog box.
2. Open the new project's
Visual SourceSafe folder and note that all the
project's files are automatically pinned
(they have a special pin icon). Visual SourceSafe
automatically pinned the files because the files
that you shared were not from the latest version
(see Figure 2.24).
FIGURE 2.24. - Pinned files in a SourceSafe
project.
3. Branch the files for module
C (the files that will need to be changed).
- Select the file or files that you will
need to modify for module C.
- Choose SourceSafe, Branch from the Visual
SourceSafe menu.
- In the Branch dialog box, write any appropriate
comments, and then click the OK button to
complete the branching operation (see Figure
2.25).
FIGURE 2.25 - The Branch dialog box.
- The branched file or files are no longer pinned, but the files that you did
not select for branching
remain pinned (see Figure 2.26).
FIGURE 2.26. A project that shows a branched file (no longer pinned).
At the end of the preceding operation,
you will have a new project that contains pinned,
shared files rom the original project and branched
files from the original project.
Because the pinned files are still shared, they are the same as the files
in the original project. Because they're pinned, a programmer working on the new
project can't check them out to change them. The branched files are no longer
shared, nor are they pinned. A programmer working on the new project can therefore
check them out and change them, without reflecting the changes back to the original
project.
