Get: Date and time, read/write vs. read only

Periodically we get the following questions about get.

  1. Is there any way to have get set the date and time on a retrieved file to be the last modified date and time from the version control repository rather than the time when it was downloaded?
  2. Is there any way to have get mark files as read/write rather than read only?

The answer to each is no for both TFS 2005 (v1) and TFS 2008 (Orcas).  It's something we considered doing in v1, but we ended up cutting it.  It remains on the list of features to consider for the future.

If you have opinions on this or other version control features, you'll want to let Mario know.

Comments (16)

  1. johnw says:

    Working in a software development organization, I understand that not all features make the bar for RTM.

    What would be helpful though, is insight into the product team’s rationale for the decision.  It may tell us that we don’t need this feature if we did x, y, or z.

  2. buckh says:


    In this case, it was lack of time for v1.  For Orcas (TFS 2008), we didn’t add it as there hasn’t been a lot of feedback about folks needing it.  I think this is another one of those issues where either folks don’t care about it at all, they really, really need it.

    I’d love to know if you have a need for it and the context around it.


  3. Keith Hill says:

    For one, there is useful information in looking at a dir listing and seeing the timestamp for when the file was last checked in.  That helps me quickly see the state of a particular bit of source code.  It is also easier to get the local time vs using tf properties.  This applies to scripts as well.  It is easier to write scripts using the file’s timestamp especially with PowerShell. Parsing the info out of tf properties is possible but kind of a pain not to mention that round-tripping using tf properties on each file to get its last modified timestamp is much slower.

  4. buckh says:

    Keith, I wouldn’t expect that you would use this feature for source code, since it would cause build problems, unless you do a clean build every time.  Make, msbuild, etc. compare the dates of the source files against the binaries to see whether something needs to be built, resulting in newer code not being built if the binaries have a date newer than the last modified date of the file.

    So I’m curious as to how you would work with it.

    Regarding PowerShell, maybe at some point we’ll have a much better story there.  ;-)  In the meantime, if you either make recursive calls or pass as many file names on a single command line as possible, you’ll minimize the round trips.


  5. burton says:

    so buck, are you saying that setting the file date of source files to the check-in/modified date might cause builds not to occur that should?

    in my opinion, setting the file date to the check-in date is critical for supporting any Team Build that would use incremental build.  setting the file date to the download date makes the build unmovable (which is bad!)  in my opinion, movability is one of the primary benefits of having a build in the first place.

    on another blog/forum, someone mentioned that this would require server changes.  why would this be the case?  wouldn’t the client set the file date in the workspace?

  6. buckh says:

    Burton, yes, setting the date and time to the checked in time is a problem for any incremental build (i.e., any build where you don’t delete all of the binaries first).  As soon as your binaries end up with dates that are later than the source files, the build won’t work correctly.  That would easily happen with builds that take a long time.

    The correct way to do incremental builds in team build in TFS 2008 is to set the IncrementalBuild property in your tfsbuild.proj file.  This will result in the binaries not being deleted before the build and only the newly changed source files will be downloaded (all of the others will have their original date/time stamps).

    The server doesn’t currently send the check in time to the client during a get.  Without doing that, a get that set the time and date to the check in time and date can’t be done efficiently.


  7. John Moreno says:

    I’ve seen two different Connect "bug reports/suggestions" for this, as well as quite a number of post complaining about it/asking how to do it.

    I know it’s been a while since this was written, but if this comment goes through, count it as another vote for adding it sometime soon.

    As for why we need it: other than the obvious (wanting to know which files were worked on recently), it’s critical for resolving differences between different branches of old projects that get migrated into TFS from VSS.

  8. John Hardin says:

    I'd like to vote for having GET set the file date to the last commit date in the repo. This is IMO a miss compared to just about any other revision control system available.

    Saying this will break incremental builds is spurious. The only way that would occur is if you did a GET _while_ you're doing an incremental build, and if you're doing that your build environment is broken.

  9. buckh says:

    John, thanks for your feedback.  We have it on the backlog for consideration for the next release.  The reason that you would not want to use this for incremental builds is that whether or not a binary should be rebuilt is based on the date of the output file (e.g., dll) compared to the dates on the input source files.


  10. John Hardin says:

    OP et. al.:

    (1) Copy this to a file named "Fix_File_Dates_From_TFS.ps1":

    Get-TfsChildItem |

     ?{$_.ItemType -eq "File"} |


       if (test-path (Split-Path $_.ServerItem -Leaf)) {

         $file = Get-Item (Split-Path $_.ServerItem -Leaf);

         if ($file.IsReadOnly) {

           $file.IsReadOnly = $false;

           $file.LastWriteTime = $_.CheckinDate

           $file.IsReadOnly = $true;




    (2) Install the TFS Power Tools

    (3) Run "Get Latest Version"

    (4) Open a TFS Powertools PowerShell console

    (5) For each directory affected by the GET, change to that directory and run the above .ps1 script


    Incremental rebuilds should rebuild a file if the source file has been changed more recently than the compiled output was generated. How will setting the file date to the last commit date on GET of  files that are not checked out break this? I would suggest that setting the file date on GET to the current date could instead lead to _unnecessary_ rebuilds.

  11. wewilder says:

    Thanks John.   We package the entire application for deployment every time.  If a modified date hasn't changed since our last build and deploy, we don't want it to change for the current one either.     Checking modified dates, especially when there is an issue,  has been a common practice at my company for many years.   The source control tool(s) we are moving from to TFS didn't mess with the dates.   Depending on how well it works for us, we may very well incorporate John's code into our build process, but it would be much better to have that option built into TFS.  

  12. wewilder says:

    In addition the summary properites are also wiped out!   I know it may seem strange, but we have users who actually use these summary fields.  I'm just hoping this doesn't end up being a show-stopper for moving forward with implementing TFS in some of our application areas.

  13. Edward Williams says:

    Hello Buck,

    Has this functionality (initial post)  been added to TFS 2010? If not, what is the next release that it is considered to be added to?

  14. buckh says:

    Edward, these are on our list for hopefully being in the next release.  Stay tuned to see how it turns out.


  15. Tom Warfield says:

    Here it is four years later – any update on whether TFS will ever include last modified date?


  16. Hey Tom,

    A few releases back, we did add the option to set the file time to either the time of the last checkin or the current time when the file is downloaded (i.e. during a Get).  We don't have any plans to take the actual time the file was last modified (i.e. by the author before they checked in) and set that the next time another user performs a Get.  This is problematic because it relies on the time of the user's machine being set correctly.


Skip to main content