A Brief SourceSafe User's Guide to Team Foundation Version Control

  • Article

Moving from one software application to another often results in various "surprises" where the new application does not behave the same way as the previous one.  Over the course of the Team Foundation beta program I have observed a number of these "surprises" that beta customers experienced who were SourceSafe users trying out Team Foundation source code control.  I have noted these changes in behavior below as a brief SourceSafe User's guide to Team Foundation Version Control.  I will blog more on this topic as new scenarios arise.

Checkout does not download the latest file - for a good reason

Checking out a file in TF does not download the latest file like the default SourceSafe behavior.  The reason TF does not download the latest file is that this could break your build on your local machine because the set of files you have on your machine are not from the same point in time (from the server's perspective).  As a developer, this is the preferred behavior because there is often a domino effect where getting the latest of one file requires getting other files that have dependent changes.  For example, suppose you check out 2 files to fix a bug only to find out half a day later that you need to modify a third file to fix the bug.  Since the time you checked out your first two files, someone else has checked in a change to the 3rd file that requires you to get 5 more files.  If checkout gets the latest files, you will also need to get the 5 additional files plus whatever new dependencies that have been added to those files.  I've seen SourceSafe user (I've done it myself) check out the entire project on purpose to avoid this scenario.

If you really want to get the latest of a file before doing a checkout in one step, you can use the following macro:

    Sub CheckoutLatest()
DTE.ExecuteCommand("File.TfsGetLatestVersion")
DTE.ExecuteCommand("File.TfsCheckOut")
End Sub

Get did not get it....literally

I've seen a number of SourceSafe users try the following:

1. They made changes to files under a folder CompanyApp
2. They want to rebuild with a version of one or more files before they made their change so they do the following:
        a. Rename their local CompanyApp folder to MyCompanyApp
        b. They do a get from source control which in effects gives them the files as they were before making their changes in source control

SourceSafe in this case would make a CompanyApp folder and place the latest files in this folder. 

TF does not get anything.  Why?  Because the server knows you already have that version locally.  For performance reasons, TF does not check the local files on disk when performing a get operation, it checks the version that you got last locally with what is in the server and decides if the file will be downloaded.

So, how do you accomplish the same goal in the scenario above?  You can do this in one of two ways.

Shelveset

Shelve your current changes and uncheck the "Preserve pending changes locally" (File, Source control, Shelve Pending Changes...).  This will save your pending changes on the server, but will undo these changes locally.  You can then build and use the files as they were before your changes.  When you want to go back to your previous changes, unshelve your previous shelveset (File, Source Control, Unshelve Pending Changes...)

Use a different workspace

Perform the get in a different workspace (which will be mapped to a different local directory).

If you deleted files locally by mistake and you want the Get operation to download the files, perform a force get by doing the following:

  • Choose the File, Source Control, Get Specific Version... menu
  • Check the "Force get of file version already in workspace" checkbox

Get of deleted files/directories will delete them locally

If a file or folder is deleted in the TF server, the next time you do a get of that file/folder your local file or folder will be deleted.  In this scenario, SourceSafe leaves your local file/folder alone. 

No sharing and pinning files/folders

Team Foundation Source Control does not support sharing and pinning.  In Team Foundation you use branching and merging.  This has already been blogged about on Buck Hodge's and Team Foundation blog.  See the following:

Sharring and Pinning:

https://blogs.msdn.com/buckh/archive/2004/06/14/155403.aspx
https://blogs.msdn.com/buckh/archive/2004/06/10/152609.aspx

Branching and Merging:

https://blogs.msdn.com/buckh/archive/2004/06/14/155417.aspx

https://blogs.msdn.com/team_foundation/archive/2005/02/23/379179.aspx

Deletes do not happen immediately

When you delete a file from a solution controlled by SourceSafe, the default behavior is to delete the file on the server immediately.  This can easily break a build if someone does a get from source control when this delete depends on another file that has not been checked in yet, say another file that still refers to the deleted file (e.g. a source file or make/project file).

With TF source control the delete is a pending change that is not reflected on the server until you do your next checkin with all associated dependencies.

The first time you delete a file with SourceSafe you are given the  following options:

  1. Delete both the local and source control store file
  2. Delete the local file now, delete the source control store file on checkin (this is the way TF works)

You may have been presented with this dialog a long time ago and accepted the defaults and checked the "Do not show again" checkbox.

Adding a solution to Team Foundation Version Control is not done immediately

When you add a solution to source control using SourceSafe the files are uploaded to the server immediately.  With TF, this is not the case.  Instead a pending add is created and the files are not uploaded until you do a checkin.