Look at Visual Source Safe

Visual SourceSafe is a useful tool supplied with Visual Studio which helps developers share Visual Basic files (called Source Control) and maintain different versions of files (Version Tracking). Source control is used to try to prevent two copies of the same file being changed at the same time. This can occur when two developers try to change the same file at the same time or when one developer accidentally opens two copies of the same file and tries to edit both of them. While this cannot be entirely prevented (source control will allow any number of developers to open the files as read-only, and these can then be changed and saved under a different file name), using a tool such as Visual SourceSafe (VSS) ensures that there is only one official version. Version tracking enables us to keep a history of the code's development by saving backup copies of the files. These backup copies can be used to recreate the original files exactly as they were at some previous point in time. We can also compare two different versions and see the differences in the two files. This allows us to pull out the precise lines of codes that have been changed.

Visual SourceSafe is a project-oriented version control system. Visual SourceSafe supports any type of Visual Basic project, including web and non-web applications, and it can keep track of changes to both text and binary files so we can use it with all of our project files. We can also use Visual SourceSafe to keep track of the relationships between files. Visual SourceSafe works with groups of files.

In addition, Visual SourceSafe has a report generator, a history tool for showing history of projects or individual files, tools to identify differences between versions of files, a tool for finding strings in text files and a tool for viewing files.

Visual SourceSafe is a tool which allows a team to work cooperatively on code and documents. However, since many readers will not have access to an entire network to explore Visual SourceSafe with, we will create an example on a single machine.

In a real implementation of a change management system, there must be a great deal of planning. It is unlikely the entire team will need access to all files. There must be a decision made on what files and documents each component team will have access to, and what files and documents each member of the team should have access to. The Visual SourceSafe database must be placed where all the team members can have access to it and check out files for editing. There must be enough disk space for the Visual SourceSafe database, and there must be enough room to allow for the expansion of the database as Visual SourceSafe begins to maintain a history of the files. A clear set of rules must be established on when and how files are checked, how they are updated and how they are changed and checked back in. All of these factors take time, planning and research. A good change management system cannot be created without first reviewing these issues.

Adding a Project to Visual SourceSafe

If you have not installed Visual SourceSafe onto a computer and you want to do the examples, install it now; it is supplied with Visual Studio. Once Visual SourceSafe has been installed, you will need to create users who are allowed to use it. To do this, go to the Windows Start menu, select Microsoft Visual Studio 6/Visual SourceSafe/Visual SourceSafe Administrator 6.0. You should begin by changing the administrator password: the default password for the administrator is blank. You can also add additional users if you need to. Once you have done this, you can go to the Windows Start menu, select Microsoft Visual Studio 6/Visual SourceSafe/Visual SourceSafe 6.0. Enter a valid user ID and password. Now open up Visual Basic and create a new project; when you save the project, you will now be asked if you want to add it to Visual SourceSafe. Save the project and add it to SourceSafe.

You will be prompted to log in when you choose to add the project to SourceSafe:

The next screen will require you to select a project to include this in. This is not the name of the Visual Basic project (though it can be the same): it is the name of the Visual SourceSafe project. If you are building an application out of many Visual Basic projects, you may want to group all of the projects into a single VSS project or give each one its own separate Visual SourceSafe project. In this screenshot, I have no VSS projects yet, so I will just save it to Proj ect1:

You may be wondering where this file is physically saved. Usually, Microsoft Visual SourceSafe is installed on a server in a development environment. Visual SourceSafe manages all of the documents it stores (these documents can be code, forms, UML diagrams, etc.). Visual SourceSafe will place these files in a special Visual SourceSafe database. The files will also be temporarily placed on one or more of the developer's hard drives as the developers check out the files for editing.

You will next be prompted to choose which files you want to save:

Save all of them. If you close the Visual SourceSafe manager and reopen it, you will see the following:

While anyone using Visual SourceSafe can use the manager, most Visual Basic developers will actually never use the Visual SourceSafe Manager or Administrator. These tools will usually be used only by the project manager. In a large corporation with many projects, the change management system would become a library that could be used by many developers. In this case, it is best if a librarian is placed in charge of the database and the change management system. The librarian will establish user rights, locations of databases and procedures and policies for the change management system. In this way the documents and code will belong to the corporation and can be available for reuse, maintenance and future upgrades.

If you return to our Visual Basic project and right mouse click on the program window, you will see the following:

If you return to our Visual Basic project and right mouse click on the program window, you will see the following:

Checking Files Out of Visual SourceSafe

You can see that we now have a few items added to the project menu. Selecting Get Latest Version will retrieve a read-only copy of the latest version of the module, so we cannot make any changes to the file. We will want to do this before we start testing. When we want to edit the module, we must remove or Check Out the file from the Visual Source Safe library. When we check out a module, a copy is written to the local hard drive. If we try to open the module before we have checked it out, we will get an error message and will not be allowed to edit. While one developer has checked it out, no other developer can also check it out for editing. However, other people can still look at the file in read-only mode, or make a copy and add a new file to the database for editing (this is called branching, which will be discussed below). This prevents two people from editing an official version of the same module. Check in saves the new edited code module back into the database and deletes the local copy. This differs from Undo Check Out, which allows us to stop editing without saving any changes.

If a code module is checked out for editing, as we discussed, the last saved version can still be viewed by another developer and even run. The second person cannot, though, change any of the code. This means that while the development team is working on a module, the testing team can be testing completed portions of the module. Thus, Visual SourceSafe allows development and testing to occur together.

Configuring VSS

Many Visual SourceSafe options can be changed. If you go to the Visual SourceSafe menu and select Tools | Options you will see the SourceSafe Option tabs:

SourceSafe Options

General | Local Files | View | Difference) Command Dialogs | Warn, f~ lAlways keep files checked outi

Act on projects recursively P Reuse Jast comment

Check in unchanged files: Use visual merge: Double-click on a file:

Editor for viewing files:

Undo CheckClut

Only if there are conflicts

Editor for viewing files:



Folder for temporary files:

1 C:\Prograrm Files\Microsoft Visual Studio\Cornmon\VSS




This option tab allows us to adjust many of the SourceSafe configuration settings, such as what action will be taken if an unchanged file is checked in, and what action to take when we double-click on a file in VSS Explorer. It is worth taking some time to look through the tabs and see what options are available.

Merging Files

Using the cyclic methodology will allow us to complete the project in steps. Each step will complete a portion of the project and will have milestones associated with it. Once the milestone is reached, we move onto the next portion of our code. When it comes to writing Visual Basic code, it is best if each step creates and completes a set of functionality of a Visual Basic component. Thus, in our first step we make the Customer component and code the properties of the bottom class. Our milestone will be the writing of the code and the debugging and testing of this code. Once this milestone is reached, we begin work in the next stage, which may include writing the methods for this class. The next stage should not be adding additional functionality to the properties written in the last stage, as this makes it difficult to update changes.

If we are adding methods or properties to a class from one stage to the next, we may run into the situation where a bug is found in an earlier stage while working in a later stage. To fix this, we will have to go back to the code from the earlier stage, fix the bug, and then merge the new version of the earlier phase into the later phase. Visual SourceSafe can do this automatically, but it is recommended to use the Visual Merge tool supplied with VSS. This works a little like Compare Documents in Microsoft Word, and allows us to view each difference between two files:

sstG074 bas: Merge t/ProjecM/ProjecM/sstßO?-! bas into $/Project4/sst6074.bas

H kl I III

»/Project4/ProjecM/sst607'l bas

28 MsgBos "Add-in is now entered m VBADDIH.INI i j. I

29 End Sub

31 Public Sub CleanFields(ByRef r_uFieldInfo ( ) As F:

32 ByRef r_sFieldNames ( ) As

33 Dim IngFieldCounter As Long

34 ReDim r_sFieldRames ( 1 To UBound(r_uFieldInfo))

35 For IngFieldCounter = 1 To UBound(r_uFieldInfo)

36 r_sFieldNames(IngFieldCounter) = r_uFieldInfo

28 MsgBoK "Add-in is now entered in VBADDItJ.INI fil

29 End Sub

31 Public Sub CleanFields(ByRef r_uFieldInfo () As Fiel

32 ByRef r_sFieldKames() As Str

33 Dim IngFieldCounter As Long

3ReDim r_sFieldNames(1 To r_uFieldInfo)

35 For IngFieldCounter = 1 To r_uFieldInfo

36 r_sFieldHames(IngFieldCounter) =r_uField!nfo

Merged version


28 MsgBox "Add-in is now entered in VBADDIN.INI

29 End Sub

31 Public Sub CleanFields(ByRef r_uFieldInfo() As Fi

32 ByRef r_sFieldNames ( ) As

33 Dim IngFieldCounter As Long

34 ReDim r_sFieldNames(1 To r_uFieldInfa)

35 For IngFieldCounter = 1 To r_uFieldInfo

36 r_sFieldNames(IngFieldCounter) = r_uField!nfo(IngFieldCounter).FieldName

Fieldlnformation, String)

Deleted lines Changed lines ¡Inserted lines |tHi |Ln 34, Col 1

Ideally, we would want to complete the bottom class in the first phase and then build other classes that used the bottom class in the second phase. This is the best way to build a project and the easiest way to maintain and debug the code.

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