Kevin.Gao.Blog()

Navigation Links:
Add introduction
Differences between SourceSafe 6 and 2005
Store only latest version
File type filter
Binary or not

Add introduction

A file must be added in a VSS database first before you can do check in, check out and other operations. To add one or more files, you can click Add File on the File menu or use drag and drop from Windows Explorer to SourceSafe Explorer.

You can also add a whole folder into SourceSafe recursively. If there are some files or sub projects in VSS already, VSS keeps the existing files and sub projects and only adds the ones not in VSS.

Differences between SourceSafe 6 and 2005

1. Different interface
   The dialog boxes of Add File in SourceSafe 6 and 2005 are quite different:


(Add File dialog box in VSS 6)

 


(Add File dialog box in VSS 2005)

 

2. Folder cannot be added in the VSS 2005 Add File dialog box. You can use Drag and Drop to add folders to VSS.
3. The files already under version control are not filtered in the VSS 2005 Add File dialog box. In the VSS 6 Add File dialog box, only the files not in the VSS database are shown. But in VSS 2005, all the files are shown. This is very inconvenient if you have tens of or even hundreds of files. For example, if you have 100 files in the VSS database already and newly added 2 files. To add the 2 new files into VSS, in VSS 6, you will see only 2 files in the Add File dialog box. But in VSS 2005, you will see 102 files and you must find the 2 new files.

The Microsoft Visual SourceSafe team is aware of this issue and they have an undocumented secret feature. By pressing the Shift button and then launch Add File dialog box, the classical VSS 6 style Add File dialog box will be brought up.

Store only latest version

There is a Store Only Latest Version option in the Add File option dialog box:

(Store only latest version option)

If this option is selected, only the file content of the latest version is stored. Even though the history information is stored as usual, when you want to retrieve the file content of the previous version, a “File [%filename] does not retain old versions of itself” error will be shown.

Since only the file content of the latest version is stored when this option is selected, the VSS database is smaller and the operations can be faster.

This option is useful when we use VSS to store files but do not care about the previous versions. For example, every time when we build a new release for our test team, we add the executable file to VSS. For this executable file, it may be desirable that we select the Store only latest version option.

You can use the following dialog box to change the option:

(File property – Store only latest version)

File type filter

In the Add File dialog box, you can use File Type combo box to filter the files, which makes it easier to find the files you are looking for:

(File type filter in VSS 2005)

(File type filter in VSS 6)

You can manage the file type group through SourceSafe Administration tool and SourceSafe Explorer. The settings specified in the SourceSafe Administration tool affect all users. The settings in the SourceSafe Explorer affect only the current user. To set file type group, select Tools -> Options menu and go to File Types tab:

(File type group)

Binary or not

In the Add File dialog box, you can specify that the file is binary:

(File type)

There are two kinds of files: binary file or not-binary file (also called mergeable file). There are two important differences between binary files and mergeable files:

1. Binary files cannot be checked out by multiple users. Even if the Allow multiple checkouts option is enabled, VSS always places exclusive lock on binary files. For mergeable files, if the Allow multiple checkouts option is enabled, multiple users can check out the files. Usually, all the program files are mergeable.
2. Binary files cannot be visually diffed. For binary files, when you do a diff, SourceSafe only tells you if the files are the same or not. For mergeable files, SourceSafe tell you which lines are untouched, which lines are changed:

You can also choose Auto-Detect to let SourceSafe decide if a file is binary or not. When you choose Auto-Detect, VSS does the following to determine if a file is binary:

1. If the file type is in the binary file extension list, the file is a binary file. Or else, go to step 2. The binary file extension list can be specified in the following interface:


(Binary file type)

 

2. If the file contains a byte with a value of 0, the file is a binary one. Or else, go to step 3
3. The file is mergeable.
   You can also change the file type after the file was added into VSS database:


(File type in file property dialog box)

 

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Working folder in SourceSafe / VSS
Next article >>>>: Get Latest in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Navigation Links:
Working folder introduction
Setting working folder
Working folder is inheritable
Clear working folder

Working folder introduction

A working folder is the specified corresponding folders on a user’s local computer used to store files when working with VSS projects. By default, the files are retrieved to the corresponding working folder when a user does Get or Check Out. A user can make changes to files in the working folder and then check the modified files back into the VSS database for version tracking.

A working folder is required for many version control commands. For example, if a working folder is not set, when you do Get Latest Version, VSS will prompt you to set a working folder for the current VSS project or else the Get operation cannot continue.

View File is the only command working on files that does not require a working folder is.

A working folder is based on per project, per user and per machine. That means one user can have different working folders for different VSS projects on one machine, different users can have different working folders for the same VSS project on the same machine and one user can have different working folders for a VSS project on different machines.

Setting working folder

To set a working folder for a VSS project, you can select a VSS project first, then click the Set Working Folder icon in the toolbar or click Set Working Folder on the File menu.

The following figure shows the Set Working Folder dialog box of VSS 6. This dialog box was designed a long time ago and we can see the old-style presentation of the UI.

(Set working folder dialog box in VSS 6)

This design was kept for more than 10 years and when Microsoft released Visual SourceSafe 2005, the SourceSafe team had a new implementation of the Set Working Folder dialog box. A system standard Browse For Folder dialog box is used.

(Set working folder dialog box in VSS 2005)

However, there is a serious flaw in the new Set Working Folder interface. I will explain it in the coming Working Folder Is Inheritable and Clearing Working Folder sections.

Working folder is inheritable

Working folder is inheritable, which means that if a working folder is set for a parent project, the sub projects automatically inherit the relative working folder from its nearest parent. For example, we have a VSS project of $/Work/WebService, with a working folder of C:\Kevin\Work\WebService. For $/Work/WebService/Res, if its working folder is not set explicitly, it has a working folder of C:\Kevin\Work\WebService\Res automatically. In most cases, it is recommended that you only need to set the working folder for a parent project and let all the sub projects inherit working folders from the parent. But if you like, you can always set working folder for any project explicitly.

If a working folder is set for a project, the project does not inherit working folders from its nearest parent anymore.

Clear working folder

Sometime, you need to clear the working folder settings of a project to make it inherit working folder from its parent.

To clear the working folder, you just set the working folder to blank.

But in the SourceSafe 2005 set working folder interface, there is NO way to set the folder to blank. If we ever set a working folder for a project in VSS 2005, there is no way to clear it so it is impossible for the project to inherit working folders from its nearest parent. This caused a huge problem for our team. Luckily, the Microsoft Visual SourceSafe had an undocumented “backdoor” to handle this problem. To bring up the VSS 6 style Set Working Folder dialog box, you need to press the Shift key and then click the toolbar icon or the menu item.

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Some Screenshots of SourceSafe
Next article >>>>: Add operation of SourceSafe
SourceSafe How To series home page: VSS / SourceSafe Tutorial

The following screenshots shows the typical interface of SourceSafe.

(Log on to VSS DB)

(Client Window)

(File History)

(Share)

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Basic operations of SourceSafe / VSS
Next article >>>>: Working Folder in SourceSafe
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Navigation Links:
Add
Get
Check Out
Check In

 
I only put basic introduction of SourceSafe / VSS version control operations in this post. For detailed information about SourceSafe operations, like Add, Get, Check In and Undo, please refer to the upcoming posts.

Add

Add is the starting point of all VSS file operations. Before you can do Get, Check In, Check Out or other operations, the file needs to be under the control of VSS first.

You can add individual files and folders into VSS database.

Screen shots of Add File:

(Screen shot: Add File in VSS 6)

(Screen shot: Add File in VSS 2005)

Get

When you want to view/get a file or project, but not modify it, you can use the Get or View command. Get copies the file or project from the current project into your working folder.

Get Latest Version, which retrieves the most recent version of a file or a project to your working folder, is the most commonly used command in VSS.

Screen Shot of Get:

(Screen shot: Get Latest)

Check Out

To make changes to a file you must first check it out of the VSS database. When you Check Out an item, VSS retrieves the latest copy of the file to your working folder and make it writable.

There are exclusive check out and non-exclusive check out. If a file is checked out exclusively, it cannot be checked out by other users.

Please always check out a file first before making any changes for the following reasons:

1. If a file is not checked out, it cannot be checked in;
2. If a file is not checked out, your local copy may not be the latest copy. Not working on a latest copy may cause extra work, overwriting other’s changes, confusion and many other problems;
3. If we change a file without checking it out first, other team members can check out the file and make changes to it, which can cause huge problem if parallel changes to a file is not desired.

This is the classical lock-modify-unlock model of VSS. Other tools like CVS and SubVersion have very different models. The latest VSS 2005 also supports the Copy-Modify-Merge model. We will discuss the details later in the coming articles.

Screen shot of Check Out:

(Screen shot: Check Out)

Check In

After you have finished the changes, you need to Check In the updated file back into VSS. When we say VSS keeps all your previous changes, we are not saying that VSS keeps every change you make, we are saying that VSS keeps all the versions you checked in. If you do not check in your file, there is no way that VSS knows that you have changed the file and it should keep it.

Screen shot of Check In:

(Screen shot: Check In)
 

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Several Important Concepts in VSS
Next article >>>>: Some Screenshots of SourceSafe
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Navigation links:
VSS Database/Repository
Master Copy and Local Copy

VSS Database/Repository

VSS database/repository is the central place where all files, history, project structures, permission and user information are stored. VSS database consists of hundreds of or even thousands of individual files with some strange names like aaaaaaa.a or baaaaaaa,a. The format of the VSS database is unknown to the public since Microsoft never published the format/specification.

Working Folder

Working folder is the specified corresponding folders on a user’s local computer used to store files when working with VSS projects. By default, the files are retrieved to the corresponding working folder when a user does Get or Check Out. A user can make changes to files in the working folder and then checks the modified files back into the VSS database for version tracking.
Working folder is required for many VSS operations. For example, if a working folder is not set, when you do Get Latest Version, VSS will prompt you to set a working folder for the current VSS project or else the Get operation cannot continue.

Master Copy and Local Copy

A master copy is a copy of a file stored in a VSS database. A local copy is a copy of a file stored in your working folder on your local computer. The reason why the copy in VSS database is called a master copy is that the VSS database is the central point for file synchronization. After you make changes to your local copy, you need to check the file into the VSS database so that your team member can access the file content changed by you. You can do Get Latest Version to retrieve the latest version. More importantly, before making any changes, you need to Check Out the file first. The Check Out operation marks the file in the VSS database as checked out and retrieves the latest version to your local hard disk.

Most version control systems have similar concepts with the ones in VSS.

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: What can SourceSafe do?
Next article >>>>:  Basic operations of SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Navigation links:
History preserving
File Difference
Project/Folder Difference
Easy Collaboration

In a nutshell, you can use VSS to keep your files, including the previous versions, in a central repository/database. Although VSS is mainly used by software developers, it can be used by anyone working with computers. VSS can store any types of files, such as source code, project plans, specification documents, database objects, and your kitchen design blue print.
 

History preserving

Let’s say you have a file, c:\work\proposal.doc. Do you have a bunch of related files that look like:
          Proposal_2008.1.1.9PM.doc
          Proposal_backup_before_changing_pricing11.doc
          Proposal.doc.back2

Or several related folders that look like:
          C:\Work_Back1
          C:\work_back2
          C:\work_back_2008.1.1

A version control system, such as VSS, can completely eliminate the need of backing up your files in the above mentioned way.

SourceSafe keeps all your versions you checked in (if “Store only latest version” option is not selected). And best of all, under normal circumstances, you see only the latest version, which make your file management much easier. Whenever you need previous versions, you can use the “Show History…” feature to access all the previous versions as shown in the following figure:

(History of Visual SourceSafe / VSS)

You can see who and when did what change and do Get and View operations on the versions.

File Difference

VSS can visually diff non-binary files, such as your C#, ASP.NET or Java source code. Word and Excel files are binary files and cannot be diffed in SourceSafe. You can view the differences between local file and any version in the VSS database, two previous versions in VSS, any two local files or any two files in the VSS database.

You can see which lines are newly added, which lines are deleted and which lines are changed, as shown in the following screenshot:

(File Difference in Visual SourceSafe / VSS)

Project/Folder Difference

Project difference feature allows you to see the differences between your local folder and VSS project, two local folders or two VSS projects:

(Project Difference in Visual SourceSafe / VSS)

The diff result shows you which files are only in the local folder, which files are only in the VSS database and which files are different. You can do version control operations, like check out, get and view, directly in this interface. There is also a powerful feature called Reconcile All, which can synchronize your whole local folder and VSS database.

Easy Collaboration

VSS makes team collaboration easy and intuitive.  When you add/check in a file to the VSS database, the file is available to other users. The team members, if they have sufficient permission, can see the latest or the previous versions of the file and can also make changes to the file. When you have multiple team members, this is really useful. Everyone can access the latest files and make changes without worrying about working on the outdated files or overwriting the changes made by other members.

When “Allow multiple checkouts” option is selected, VSS also supports parallel development, which allows individual team members to work on different parts of a file at the same time.

(Allow Multiple-Checkouts in Visual SourceSafe / VSS)

The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Market position of SourceSafe
Next article >>>>: Several Important Concepts in VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial