Visual Source Safe Scenarios

There are two common scenarios with Visual Basic projects. In the first case, we do not expect to change many files. In the second case, we may be changing several files, potentially several times. Visual SourceSafe has two different features to cope with these scenarios. In the first case, we would use Visual SourceSafe's label-promotion feature. In the second case, we would use Share/Pin/Branch.

Label Promotion is the best method to use when your development is done in the same project tree and bug fixes are routinely performed before other changes have been made in the project. A common example is when working on a major release with several milestones, such as Beta 1 and Beta 2. In this instance, we would label the project when we believe we have completed Beta 1, then continue working toward Beta 2. If few fixes are needed for Beta 1, use the label-promotion feature.

Share/Pin/Branch is the best method to use for parallel development on a project over an extended period of time. A common example is when we are working on two releases that share code, both of which have milestones. For example, we have shipped Version 1.0 and now we are working on Version 2.0; however, an interim patch for several bug fixes is needed. This patch will be released as Version 1.1. In this instance, we would work on Version 2.0 and Version 1.1 in different project trees, then merge changes between them as necessary.

The following are three scenarios using the label-promotion feature. For completeness, a fourth scenario using share, pin, and branch is described. These scenarios are presented as a guide.

Scenario #1: Component Development

In this scenario, we are building the project from components. At each release, a component is completed and will not be changed in the next release. Thus, Release 2 does not change Release 1 code; it only adds additional modules to the project.

> Develop and test the project in the drive toward Release 1.

> At the point where Release 1 is completely tested, label the project, for example: "Release 1".

> Begin working on Release 2.

Scenario #2: Changing Files in an Unchanged Previous Release

We will be developing as in Scenario 1, i.e. building separate components in each release. After we have moved to Release 2, we discover there is a major flaw in Release 1 in files that have not been changed while working on Release 2. Release 1 could be in use by the client or the flaw may prevent proper testing of Release 2. Release 1 needs to be fixed and recompiled.

> Develop and test the project in the drive toward Release 1.

> At the point where we are ready to go to Release 1, label the project "Release 1" (or something similar).

> Begin working on Release 2.

> At this point, we realize that the file included in Release 1 has a bug in it that must be fixed. No other files in the project have yet changed.

> Check out the file, make the changes, then check it back in.

> Label the project "Release 1" again. (You'll be asked to confirm that you want to remove the old label). Projects using version 1 files will not have to be changed. If you want to maintain the original version, rename it Release 1.1 and include the new Release 1.1 files in all of the projects using the Release 1 files.

Scenario #3: Changing Files in an Altered Previous Release

We will be developing as in Scenario 1, i.e. building separate components in each release. After we have moved to Release 2, we discover there is a major flaw in Release 1 in files that have been changed while working on Release 2 (for example: a class may have had additional methods or properties added). Release 1 could be in use by the client, or the flaw may prevent proper testing of Release 2. Release 1 needs to be fixed and recompiled.

> Develop and test the project in the drive toward Release 1.

> At the point where we are ready to go to Release 1, give the project an appropriate label, such as "Release 1".

> Begin working on Release 2.

> As in Scenario#2, we now realize that the file included in Release 1 has a bug in it that must be fixed. However, this time other files in the project have also been changed and those changes have been checked in.

> Check out the original Release 1 copy of the files that need to changed, make the required changes, and then check the files back in, creating a new version.

> Label the file "Release 1" (the same label we gave to the project). This promotes the new version of that file into the project with the label "Release 1".

> Now, if we retrieve the Release 1 project, we will get the project the way it was at the date and time when we labeled it "Release 1", except that we will retrieve the newer version of the file we just labeled individually as "Release 1". This allows us to update specific files in an old version, even after changes have been made to other files.

Scenario #4: Share, Pin and Branch to Create Service Pack Projects to Fix Major Bugs

If the need arises for a bug fix after a project has been labeled and further developed, we can use the following share, pin and branch scenario.

Sharing allows one file or set of files to belong to multiple projects. Unless the file is branched after sharing, each project will have a reference to the shared file: if the file is changed in one project, it will also be changed in the other.

Branching is the process of sharing a file with another project and then separating it into two or more branches. Once a branch has been created, two files (the file in the project and its counterpart in another project) will have a shared history up to a certain point and divergent histories after that time. Branching a file breaks the shared link, making the file in that project independent of all other projects.

Pinning is generally used with shared files, although it is not limited to shared files: we can pin any file. When we pin a shared file, we cannot make any further changes to it. Pinning is like sticking a pin into the file so that a particular version of the file becomes the version that is part of the project. If a pinned version of a file is shared, the projects sharing the file cannot change it. If a file is shared first and then pinned in one project, other projects can still change and update the file.

> In the drive toward Version 1.0, develop and test your project (e.g. $/Application).

> When Version 1.0 has been achieved, label the project "Version 1.0".

> Begin changing files in the project in the drive toward Version 2.0 of the project, which will introduce new features.

> If we now realize that an interim Version 1.1 is needed for bug fixes, select the project in SourceSafe Explorer. Then, on the Tools menu, click Show History to display the History Options dialog box:

Select the Include Labels box and click on OK to display the History of Project dialog box:

! History of Project VCodeGeneratoi

History: 10 items jDjxj

Close

! History of Project VCodeGeneratoi

History: 10 items

Name 1 User

|Date

I Action

FormUrm Admin

8/09/991S

19

Added

CodeGeneratorCI Admin

8/09/9910

19

Added

BuildTop.bas Admin

8/09/9918

19

Added

BulldServer.bas Admin

8/09/9918

19

Added

BuildMiddle.bas Admin

9/09/9918

19

Added

BuildBottom.bas Admin

8/09/9918

19

Added

BuildBas.bas Admin

9/09/9918

19

Added

basMain.bas Admin

8/09/9918

19

Added

CodeGenerator.vlAdmin

9/09/9918

19

Added

Admin

8/09/9918

19

Check Out

Share

Report

Details

Check Out

Share

Report

Help

> Select the version labeled "Version 1.0" and click Share. The Share from Project dialog box will appear:

Select the project you want the new project to be part of. This will usually be $/project. We want to fix the bugs in both projects, so ensure that the Branch after Share box is not be checked; otherwise, we will have to make the changes independently to both projects. Now click on OK to display the Share Project dialog box:

> Give the project a New Name (e.g., $/Application V 1.1). If the project has subprojects, select Recursive; this will ensure that all subprojects are also shared. Add any comments in the Comment box as needed, then click OK. Click Close to exit the History of Project dialog box.

> Select the newly created project $/Application V 1.1. All files in this project will 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. You can later merge bug fix changes back into your Version 2.0 project.

Was this article helpful?

0 0
365 Days Of Motivation

365 Days Of Motivation

Stop Wasting Time And Learn How To Stay Motivated. Finally! Discover How To Stop Your Mind From Wandering, And Upgrade Your Motivation. You Can Hack Your Motivation Levels, Allowing You To Take Your Life To The Next Level.

Get My Free Ebook


Post a comment