Visual SourceSafe - need to go back to a labeled version

[MMock]

I worked on some code and unit and systems tested it and now it is in the hands of the customer to do user sign-off then it will go into production. The project is a VB.NET Visual Studio 2008 project and I have it all checked in to SourceSafe. I labeled the version Release #1 and continued to work on it for the next release. So in VSS, if you look at the history of a module you might see:

5 	MMock 8/03/10 11:17a
<label> MMock 7/26/10 1:29p
4 	MMock 6/17/10 3:29p
3 	MMock 6/10/10 12:14p
etc

The user found an error. I want to make the fix to the labeled Version, not Version 5, and rebuild it. I pretty much understand how to do this - just get the labeled modules in the project. However, I don't understand this person's point:

Click the label you wish to retrieve and then click Get on the right hand side of the screen (see Figure 15). This will cause all of the files with this label to be copied to the working directory assigned to this project. As mentioned, you will not be able to check out any files from a labeled release. This prevents anyone from tampering with that released set of files.

I have to be able to "tamper" with them - that is how I am going to fix the bug. (The article that is excerpted from ishere.)

Is there a better approach than what I am trying to do?

Thanks.

[techgnome]

After you get the correct version.... do a Checkout WITHOUT GETTING LOCAL COPY.... That will check it out to you ... using that version... that will release the read-only lock on the file... THE problem is what to do when you check it back in (if you want to check it in) as it will NOT have the changes from version 5... so if you check it in with your Ver4 fix, you will lose your V5 changes...

What you can do is once you have made your change and shipped it, undo the check out, then check it out normally, do the change again, this time in the most recent version of the file(s) and then check that in (making it V6.)

Did that help at all?

-tg

[MMock]

Yes, that's pretty much what I was thinking.

Did I label it prematurely? Once you label it, that is supposed to be represent a released-to-production set of code? But you can still find bugs in released code and want to change the released revision and not pick up current code until the next release. I just want to make sure I'm using SourceSafe correctly.

What I was thinking was take all my code which represents the labeled version and recent changes. Copy it all to a new project called 2.1. 2.0 is my almost-in-production first version. I could roll back all the changes in all the modules back down to the labeled set in 2.0. Then 2.0 wouldn't have any changes after the labeled revision unless there was a bug fix. (It seems that is more in line with how this company does it).

Does that make sense?

[RobDog888]

You can "branch" off the labeled release version to a patch release folder or such. Then check it out, modify code, check it back in and send out the build. From VSS help...

In VSS, one file can be shared among multiple projects. Changes to the file from one project are automatically seen by other projects sharing the file. This encourages code reuse. Use the Links tab in the Properties command on the File menu to see a list of projects sharing a file.

Branching is the process of taking a file in two directions (that is, branches or paths) at once. VSS keeps track of these branches by tracking the different paths as a project.

Note In other (nonproject-oriented) version control systems, branches are tracked through extended version numbers: for example, version "2.3.9.2" is the second revision of the ninth branch of version 2.3. In VSS, however, branches are tracked with different and distinct project names.
Branching a file breaks the shared link, making the file in that project independent of all other projects. The changes you make in the file are not reflected elsewhere, and vice versa. A branch has been created: two files (the file in the project, and its counterpart in other projects) have a shared history up to a certain point, and divergent histories after that time.

After you branch a file, the Links tab does not show the link that has been broken. Instead, you use the Paths tab (also available from the Properties command on the File menu) to view the branch history of the file.