Freetutes.com

VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

VB .NET - Learn Visual Basic .NET

Systems Analysis - System analysis and Design tutorial for Software Engineering


You are here: Visual Basic > Advanced VB6 tutorial > Chapter 2

Pinning an Earlier Version of a File for Use in the Current Version of a Project

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).

    Selecting an older, labeled version of a project in the History of Project dialog box.
    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.

    Selecting the appropriate parent project in the Share From 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.

    Naming the new maintenance project in the Share From 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).

Pinned files in a SourceSafe project.
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).

    The Branch dialog box.
    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).

    A project that shows a branched file
    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.


  

<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © Freetutes.com | All Rights Reserved