timestamp when Getting Latest from TFS and does it matter?

Question

I'm not sure why I never noticed this before but when I "Get Latest" from TFS, the date and time on the files in my local working folder are set to the current date and time. This applies to the Created and Modified dates, even if no changes have been made (as I just did "Get Latest", nothing more).

Should I be concerned about the dates and times of the files not reflecting the true date and time the file was created and subsequently modified? I have the revision history in TFS so I'm not overly concerned but I gotta admit this feels wrong. Everything technically works but I want to know what's going on.

Answer 1

As you note, the default behavior in Team Foundation Server is to write file times to the "current" time (when you retrieved the file.) This is the default behavior of most version control tools and generally considered safe.

Setting time to the remote time can have negative consequences in many scenarios. For example, make will scan for files newer than the last build time. Setting file times to the server's time can impact the ability to determine which files have changed since the last build.

However, if you do prefer this behavior and are using at least TFS 2012 and Visual Studio 2012, you can enable it on a per-Workspace basis by setting "File Time" to "Checkin":

Additional details from Microsoft:

File Time:

• Choose Checkin if you want the date and time stamp of each file to generally match the stamp of the changeset of the version in your workspace. A few issues and exceptions are:

  • When you modify the local file, the date and time stamp will match the date and time when you modified the file.

  • This feature is available only if you are using Visual Studio 2012 or later and Visual Studio Team Foundation Server 2012 or later.

  • The setting does not apply to folders, unless there is a pending add or delete operation to a file contained by the folder.

  • You might not be able to build your code project incrementally. Instead, you will have to rebuild).

• Choose Current if you want the date and time stamp to match the date and time when you last modified the local file. For example, a team member checked in the latest change to the file on Monday. On Tuesday, you perform a get operation to update the file. The date and time stamp is set to Tuesday.

Answer 2

As mentioned, that is the default behavior of TFS. It's the fist version control system I've used where that is the default setting. The problem with using current time for files when a developer gets latest, is that you can only tell if you have the latest version by doing a file compare on each file. Three different developers on the same project will have 3 different date time values for the same version of a file. Either way, always do a project clean before creating builds. Why? Because you might have tweaked a file or two, then after testing, reverted to the latest checked-in version. In my experience it's always better to use the checked-in time.