Using Visual SourceSafe - Get Latest
This article is a part of SourceSafe / VSS Tutorial
Get Latest Version Basics
Get Latest, along with Check Out and Check In, is one of the most common operations in many version control systems.
The screen shot of Get Latest Version:
(Get Latest Version screen shot)
The Get Latest Version command retrieves the latest or the pinned version of the files to our local disk. For pinned files, the pinned version is retrieved, instead of the latest version.
A working folder is required for the Get Latest Version command.
The Get Latest Version command is the most commonly used command in SourceSafe. Usually when we come to work in the morning, want to compile a solution, or simply want to view the changes by our team members, we do Get Latest Version.
To get the previous versions by date, version or label, we need to use Show History command and then work on the previous versions.
The Get Latest Version can automatically detect which files are changed and only get the changed files. So even if we have a huge project, there is no problem, just go ahead and carry out the Get Latest Version function. There will be no big performance penalty. There is an option in VSS to let us specify how VSS determines if our local copy is the latest one. I will talk about the option in the following section.
How does VSS determine if our local copy is the latest version?
The interface for specifying how VSS compares files:
(Compare files by)
The default option is checksum, which is enough for most cases.
VSS compares our local file against the database version byte by byte. If we choose this option, the performance of get, check in and check out will be much slower.
This is the trickiest option. Even the explanation in the SourceSafe official help document is not completely correct.
This is the default option, which is enough for most cases. According to Microsoft, comparison by checksum is the fastest way.VSS uses 4-byte/32-bit CRC checksum. Since CRC is not strong enough (much weaker than MD4 or MD5), there is possibility of collision (different file contents have the same checksum).
When we try to get the latest of a project, if we select the Recursive option, a Build tree option is shown:
(Build tree option in Get Latest dialog box)
What does Build tree mean? When the Build tree option is not selected, if a sub project has a working folder explicitly set, the files under that project will be retrieved to the working folder. When the Build tree option is selected, VSS ignores/overrides the working folders setting of the sub projects and retrieves the files to the relative sub folders according to the VSS database project structure.
For example, we have $/working/projects with the working folder set to C:\VSS\working\projects, and $/working/projects/SCCManager with the working folder set to D:\SCCManager. When we do Get Latest recursively on $/working/projects, all the files directly under $/working/projects are retrieved to C:\VSS\working\projects. That is for sure. If the Build tree option is selected, all the files under $/working/projects/SCCManager will be retrieved to C:\VSS\working\projects\SCCManager (the working folder setting of $/working/projects/SCCManager is overridden). If the Build tree option is not selected, all the files under $/working/projects/SCCManager will be retrieved to D:\SCCManager (the working folder setting of $/working/projects/SCCManager is used).
Set file time
(Set file time)
When we do Get or Check out, VSS allows us to choose how VSS sets the file time.
Before we talk about the options, I need to point out that the time setting mechanism in VSS has issues if we have a distributed team. VSS was designed for local teams more than 10 years ago. Time zone difference is not incorporated into the design.
Let’s see an example. We have 2 developers using VSS. One is in North America east coast using east time and another is in west coast using pacific time. If the developer checked in a file from the east coast office at 10:00AM ET, and then if another developer checks out the file from the west coast office using check in time for the set file time option, the time of the file will be set to 10:00 AM. That is 10:00AM pacific time, not east time.
So why does this can cause problem? The answer is that if our developers are all in the same time zone, there is no problem at all. But if not, there are problems:
- The modification time in the file list of the main interface will be totally messed up:
(Modification time is messed up)
Depending on the time zone of the machine that the file is checked in through, the modification time listed here represents the time in different time zones.
- Our compiler may not be able to compile our solution correctly.
Most compilers use time to determine if a file is changed and only compile the changed files. If we choose Modification or Check In for the Set File Time option, we have to rebuild the whole project/solution all the time. If we choose Current for the Set File Time option, our compiler can work properly, since the files are set to the local time when we retrieve the file.
Set file time
It is Current.
The local time when we do the command.
The modification of the file when the file was checked in.
The date and time when the file was checked in.
There is a very important concept in SourceSafe: VSS treats read-only and writable files very differently and overwrites read-only files without any warning or prompt. By default, after we add a file into VSS database, the file is set to read-only. And only after we check that file out, the file is set to writable. Under any other circumstances, the file is read-only. When we do Get or Check out, if the local file is read-only, no matter if the file content is the same as the one in VSS database, VSS overwrites the file.
Best practice: never change the read-only property of a file manually if that file is under VSS control.
VSS lets us specify how it replaces the local writable copy:
This is actually Ask.
VSS shows a dialog box to ask us to choose replace, skip or merge if the content of the local file is different from the one in VSS database.
Overwrite the local copy. Use this option very carefully, since VSS overwrites our local changes.
Leave the local copy. The content in the VSS database will not be retrieved to our local disk.
If we have checked the file out and made some changes, VSS uses its merge tool to merge the changes for us.
The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement
The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft