How to build without having the timestamp change on every file in the build’s workspace

A question came up a couple of times recently about an issue with the timestamps on the files involved in a build always being the current time.  The issue is that folks have customized their deployment process to deploy only files where the timestamps are newer.  Folks then ask for an option to have get set the timestamp to the timestamp when the file was checked rather than when it was downloaded.  I don’t think that’s the best answer in this case (and if you aren’t doing a clean build, it’s not an answer at all, since that will lead to botched builds).

The biggest culprit here is likely that the default behavior for Team Build is to create a new workspace and get all of the files for every build.  We’ve left that default in place in for TFS 2008, but we may change it in the future.

You can change Team Build to get only the files that have changed since the last build by having it not create a new workspace each time and doing an incremental get.  Aaron wrote a post about how to do incremental gets in TFS 2005.  It’s a simple matter of setting IncrementalGet to true in TFS 2008.

After making the appropriate change, you’ll want to switch to incremental builds if you need to have the binaries updated only when the corresponding source files change (there are links for that in the posts referenced earlier).

Comments (25)

  1. Matt says:

    This is great, but sometimes we need to create a new workspace and pull files.  It would be VERY helpful to have a tf get option to timestamp the files with the checked-in date.  This is one VSS feature that’s sorely missed.

  2. Buck Hodges says:

    Okay, I can see it being useful in that scenario.


  3. Rob Caron on A Hitchhiker’s Guide To Visual Studio 2008, Part II. Mike Ellis on Software Process Improvement…

  4. Ted Furuya says:

    I agree this feature would be extremely useful.  Any news if this is in the pipeline either for a service pack or the next release?

  5. Buck Hodges says:

    Ted, we have a feature on our backlog for a release after 2010 to have version control support setting the file dates and times to the checkin dates and times.  We’ve received this request a number of times, so we’re aware of it’s importance.


  6. Paul says:

    Why can’t this be added as an update for VS2008?  We will not switch to VS2010 or the corresponding TFS for two years or so.  Some of our applications require extensive documentation on what files are changed for each release and not having the correct timestamp will cause a lot of pain.  It would be a deal breaker for me but that is not my decision.

  7. Buck Hodges says:

    Paul, incremental gets will give you this today.  We have a feature on the backlog for version control to maintain the dates on disk, which is what we need in order to have build be able to create a workspace and get all files every time with the original dates.


  8. Paul says:


    I just did a "get latest" which updated approximately 25 files and all of them had the current date/time.  How can you do an incremental "get" with TFS and preserve the correct timestamps?  I am trying to do a "get" to update files on my local PC while doing development.

    I understand that MS is planning on adding this "feature" some time in the future but is it impossible to patch 2008 to correct this problem?  With KFA’s (due to Sarbaines-Oxley) we have to document all files with a different time stamp so there are some systems that will never change to TFS for source control until this problem is fixed.  This is causing no end of problems for us.



  9. Buck Hodges says:

    Paul, no there is no patch for this.  This is on our list to consider for the next release.  Sorry that I don’t have better news for you.


  10. Paul says:


    What does "next release" mean?  The next full version after VS2010?  VS2010-SP1?  With all of the requests for this option for three years now, why is it not already implemented?


  11. Buck Hodges says:

    Paul, that means it’s on our feature backlog to consider for the next major release.  I can’t say for sure whether it will make it into the product for the next release after 2010 (sorry, I just can’t commit to something I don’t control).  It’s not likely that we’d introduce this feature in SP1 for 2010.


  12. Paul says:


    This will by my last post on the issue since it seems hopeless.  What I cannot understand is the logic to leave it out in TFS2005 and then not implement it after three years of complaints.  There is no reason this feature is not in VS2010.  Unless TFS is poorly designed or implemented it should not be a large effort.  With all of the requests and complaints it is hard to believe that this option is still lacking.  Is your change structure so bureaucratic that getting something in like this takes half a decade?  We have applications that fall under Sarbaines-Oxley where all changes to the source code have to be documented.  The file timestamp is part of that process.  TFS is simply useless for these applications but we are suppsed to use it.  Yes, I’m irritated but I will not complain about it again.  It just doesn’t seem to help.


  13. Buck Hodges says:

    Paul, I agree it is not a large change.  We actually have a list of "not large changes" that is amazingly long.  While we do get requests for this particular feature, it wasn’t as high as other things that made it into 2010.  I’ve forwarded your comments to our PM for version control with my own support for this feature, and I assure you it will get serious consideration for the next release e(though I know you want commitment, not consideration – I can’t commit the team to this feature or any other unilaterally).

    As for SOX compliance, I would have expected you would need to show that the file is unmodified with respect to what’s in version control.  Is just the time/date stamp on the file sufficient for SOX?  Time/date stamps are easily fudged.  A feature we added in 2008 called Folder Compare (or Folder Diff) will show you which files, if any, in the tree differ from what’s in the version control repository.  It uses the hash codes for the files from the servers to compute that.  It’s available both from the GUI and from tf.exe command line (


  14. Manish Jain says:

    I'm another victim of this situation. We are suffering since 2007. We need VSS like feature where tf get don't change file timestamp. We are using IncrementalGet but several situations when workspace is messed up due to build issues (today again!) and this is a big mess to clean up. Only way I've now is to diff to main branch and retrieve files manually. This is unacceptable!

  15. kim says:

    Any news on this feature? will it make to 2012?

  16. Buck Hodges says:

    Kim, we are adding (assuming nothing goes wrong) a feature to the next release, code-named TFS 11, to have an option on the workspace to indicate whether gets should set the time to the current time or the checked in time for downloaded files.

    We are not currently exposing this as a property on the builds.  The reason is that the only way to get a correct build when this option of checked in time is used is to use a clean build.  For the scenario of incremental depolyment, that means that all of the binaries would have the current time stamp, so it defeats the purpose.  Doing an incremental build with the file time being checked in time will lead to builds where the output is incorrect because the time stamp on the input file is not newer than the output file even though the contents have changed (think of checkins that are happening while a build is currently running).


  17. Kim says:

    Thanks I'm not using TFSbuild is this scenario. But try to create a job for creating hotfixes and needs the last checkin timestamp.

    In TFS2010 I'm setting the timestamp of the file using

    var workspaceInfo = Workstation.Current.GetLocalWorkspaceInfo(filepath);

    var projectCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(workspaceInfo.ServerUri);

    VersionControlServer versionControl = projectCollection.GetService<VersionControlServer>();

    DateTime CheckInTime = versionControl.GetItem(filepath).CheckinDate;

    But the problem is that a branch is returned as a checkin, so is it possible to get the checkin for the last add/edit of a file in the entire branch hierarchy?


  18. Buck Hodges says:

    Kim, it sounds like you want the latest changeset in the branch hierarchy.  For that you'll want to use QueryHistory().  Here's what should give you that.


    VersionSpec.Latest,            // version of that path

    0,                                             // deletion ID (0 = not deleted)

    RecursionType.Full,            // entire tree – full recursion

    null,                                         // include changesets from all users

    VersionSpec.Latest,            // start at latest

    VersionSpec.Latest,            // end at latest

    1,                                             // only return this many

    false,                                      // we don't want the files changed, just the metadata (the date in your case)

    true)                                       // history of the path


  19. Craigfis says:

    Ugh, just ran into this problem also. We need the timestamps maintained in the build. Otherwise, what is being deployed doesn't match what is in TFS and we lose traceability of changes.

  20. Buck Hodges says:

    Craigis, do you do clean builds?

    In TFS 11 beta, there's an option for a workspace to use the checkin times rather than the current times for the files that are downloaded via get.  The only safe way to build when using it is to do a clean build (i.e., build everything so that there is no date/time checking to build only what's changed since the last build).


  21. Paul says:

    Checkin time?  Really?  If you are going through the bother to add something that you think will break builds, why not add what people have been asking for the last six years: the file's actual timestamp!  The checkin time cannot be used to check whether a local .aspx page is the same as the UA or prod copy so it is not an improvement over the current situation.  

    I work on many applications and we are required to remove our local copy of the source when we are done with a project.  When I do a get on a web application my only option is to do a complete update of the UA copy since I have no way to know whether my local copy is newer than UA or not.  The checkin time is similarly useless in this case.  What is the problem with getting the file's correct timestamp?  Do we have to wait for TFS's replacement another 10 years in the future?  I'll shut up now.


  22. Buck Hodges says:

    Paul, timestamps on local files can be manipulated, but the timestamp from the server is auditable (assuming the SQL Server is locked down).  At least, that's what I expected.  Are you in an environment where you need auditability?


  23. Allan says:

    We are experiencing the same problem as well…very disappointing.

  24. Tracy says:

    Current timestamp behavior makes msdeploy largely worthless for usage with Team Build, unless the site in question is tiny or unless the site is hosted on corporate LAN. Build server creates a workspace, all files have current timestamp; lo and behold the current time is newer than EVERY FILE on the target server.

    I'm with Paul, reading through this thread of delays and excuses is a bit sad–especially considering that it's seven years old, almost as old as TFS itself.

  25. Nagsen says:

    We are using TFS2013 and still I don’t see this basic important feature not implemented. Sad state of affairs

Skip to main content