Conceptually, the internal structure of a Visual SourceSafe database and that of a Team Foundation source control server is similar. Both databases and servers are organized hierarchically. Folders contain files. Files consist of versions that are identified by number and date/time of creation.
Team Foundation advances a concept called a changeset. This concept does not exist in Visual SourceSafe. A changeset is a logical container in which Team Foundation stores everything related to a single check-in operation, such as file and folder revisions, links to related work items, check-in notes, a check-in comment, and other information such as who submitted the change. For more information, see Working with Version Control Changesets.
In Visual SourceSafe, you need to do an explicit check-out and check-in only if you are editing a file. In Team Foundation, every action requires an explicit check-out and check-in.
By default Team Foundation does not perform a silent Get operation when you check out a file.
In Team Foundation, multiple users can check out and make changes to the same item concurrently. In Visual SourceSafe, checkouts are exclusive, by default. However, you can lock a file in Team Foundation to prevent other users from checking it out or checking in changes. For more information, see Understanding Lock Types.
Branch and merge Visual SourceSafe has very basic support of branch and merge because Visual SourceSafe does not store the merge history between two branches of files or folders. However, Team Foundation version control does have support for merge history. Without merge history, you end up doing baseless merges in Visual SourceSafe.
Get latest on check-out
When you check out a file in Visual SourceSafe, Visual SourceSafe retrieves the latest version of the file from source control. You can configure the checkout behavior in Team Foundation version control in two ways. If you want the checkout behavior to be the same as Visual SourceSafe, you can configure the checkout settings to get the latest version of items when checking them out. For more information, see How to: Configure Check-Out Settings.
You can also configure the check-out behavior to mark the local copy of the file as checked out without getting the latest version from the server. This check-out behavior is useful when you perform a get operation to retrieve a set of files. Typically, the configuration of source files on your computer represents a point-in-time snapshot of specific files, which are known to work together, from the Team Foundation version control. Therefore they can be built and tested together.
As a developer working in a workspace, you are isolated from the changes made by other developers. You control when you want to accept changes from other developers by performing a get operation, as appropriate. Ideally when you do this, you will update the entire configuration of source, and not just one or two files. The reason for this is that changes in one file typically depend on corresponding changes to other files. This check-out behavior ensures that you always have a consistent snapshot of source that can be built and tested.
When you check in your changes, Team Foundation will merge your changes with any changes that were made on the server version. You will be prompted with the resolve conflicts dialog box if any conflicts are detected.