timestamp when Getting Latest from TFS and does it

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

TFS should not modify original File attributes in Source Control processing. Its build features should use their own properties to control latest checked in versions and for build control. Getting files from TFS should place the original file back down on a system with their original properties unmodified. TFS is broken by hijacking the original file's properties for its own purposes. The original Microsoft VSS tool provided this option - shame on the TFS team.

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.

Answer 3

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 4

I am also searching for this as my Employer is not ready to move to latest TFS version today I came across this TFS Source Control Explorer Extension and after installing this plugin I am able to get the files with check-in time stamp. If any one still looking get files with check-in time stamp for TFS 2010 and client as VS 2010 this should do the trick.