File Date in TFS-VC


  • In SourceSafe, you can specify (via Tools à Options… à Local Files) that the date/time of the local file be one of:

    • Current
    • Modification
    • Check in

    As a policy, we have gone with Modification as the date/time that all local files should have (mainly so that we can easily see when the file was last modified).


    How can I do the same in TFS-VC?  From what I can tell, it defaults to Current and there’s no option in the UI for changing this.  How can I make TFS-VC use Modification date instead?

    Monday, April 10, 2006 6:48 PM


All replies

  • Unfortunately TFS v1 doesn't have this feature.
    Monday, April 10, 2006 8:39 PM
  • Hilarious.

    I guess this won't be included in the Visal Studio 2005 SP1 either?
    Monday, July 24, 2006 12:58 PM
  • No, sorry.  Use 'tf properties.'
    Monday, July 24, 2006 5:29 PM
  • Any chance that the TFPT (Team Foundation Power Tools) will support this in the near future?
    Tuesday, March 13, 2007 12:32 PM
  • To do this would require some major changes to the server code, so I doubt we will see it in a power toy in the near future.  It is feedback that I know the team have heard from other people though.

    It may help if you explain why you want "Modified Date" so that the team can better understand the requirement and prioritize it appropriately. 

    TFS handles timezone issues a lot better than VSS ever did.  In terms of the modification date - would you want your local copy of the file to have a modification date/time that is the same as the time that the file was last modifed on another users machine or when it was last checked in to TFS?  Also, would the modified time be adjusted for time zone differences (i.e. if I was downloading a file from my computer set to Seattle time and the file was edited and checked in from a computer in (say) Chicago at 12.00pm, would you expect the modification time on the file to say "12.00pm" or "10.00am"?

    Many thanks,

    Wednesday, March 14, 2007 7:21 AM
  • Martin,

    At my company, we used VSS for many years, and most people are used to be able to for how long a file has not been changed by just checking the file date. In VSS, this was displayed both as the file date (in the Windows Explorer), and it was displayed in the "Date-Time" column directly in VSS. This was in fact one of the largest complaints our developers had when we switched to using TeamSystem Source Control.

    That is though rather cosmetical, the "History" function in TFSC is of course great. The one major problem we have is the following: We have different teams which work on different projects, and most of the share some libraries. These libraries are built from scratch each night, and the headers are deployed to a file share from where they are copied into the different teams. Well, the date stamps of these files change each night, so even if the library has not changed in the headers (and thus a rebuild due to library changes is not necessary), the team's projects have to be rebuilt at the developer's computer each morning, which is quite time consuming...

    We're starting to get used to it :-)

    As for the time zones: I would expect each file to have the correct "global" time stamp, i.e. if I check in a file here (GMT+1) at 10:00, I would expect the file stamp to be 11:00 at GMT, and 09:00 GMT+2.

    Perhaps a silly question: Why would it require server code changes to set the corresponding time stamp on the file; every information needed is available (through tf properties or the TFSC API), or am I missing something? Would it break the workspace if I set the file date to something else than the Source Control Explorer does?

    Best regards,
    Thursday, March 15, 2007 8:06 AM
  • we had to move our Team Build that uses incremental build to a different box (the original box died, and the backup was unrecoverable [read: really bad day]). As far as timezones are concerned, i would expect it to act just as if I were copying the files between two boxes in different time zones.  the scenario would be that if my incremental build originally ran on BUILD1 in zone A and build outputs were stored on DROPSERVER in zone B, and i had to move those outputs to the Binaries folder on BUILD2 in zone C, and then create a new workspace and get the sources from a label, then I would want the source files to be stamped based on the same algorithm as the copy, so that the incremental build still worked as expected.
    Monday, April 16, 2007 3:09 PM
  • We were also using this feature in VSS and disappointed to see it not in TFS.
    We found it useful for all sorts of things, one of which being reducing clickonce downloads, another being general at a glance understanding of what changed and when.

    The answer to the earlier question about developers in different timezones is obvious - set the UTC time of the local file to the UTC time of the checkin.

    Thursday, February 12, 2009 9:19 PM
  • We were considering a transfer from VSS to TFS for VHDL (i.e. no connection to Visual Studio at all). But this has been postponed untill TFS will have the same options as VSS: i.e. to let the developers see the expected timestamps - the "Last Modified Time" - in Windows Explorer after Checkout/Get.

    So I hope this option will be available soon!

    Monday, February 16, 2009 3:03 PM
  • Martin,

    Obviously you at Microsoft must verify that the intended version of items has been deployed.  I verify by confirming the "modified date" returned from a "dir" command, or by looking at the item in Explorer.  Without giving away too many secrets, how do you at Microsoft perform this verification task?

    Thank you,  David

    • Edited by David C Chgo Thursday, April 29, 2010 6:17 PM spelling
    Thursday, April 29, 2010 6:08 PM
  • It's not a secret.  Metadata about workspace mappings, pending changes, and currently downloaded items are stored on the server.  In the rare case that local items get out of sync w/ what the server thinks you have, you can check the overwrite checkboxes in the "Get Specific..." dialog.

    Thursday, April 29, 2010 8:22 PM
  • Hi Martin -
    Is there a way to get last modified date of an item using TFS APIs?

    Monday, June 21, 2010 5:41 AM
  • Not to go into huge detail, but yes, our company needs to have a File Last Modification Date/Time available in TFS, or we can't adopt it.

    This needs to be an option, such as VSS has, to "Set date/time on local files" either "Current", "Modification", or "Check-In". Then we (and everyone else) will be able to choose how we want checked-out files handled.

    Adding such an option would be extremely simple, *IF* the TFS database already has a column to hold the Modification Date. If it doesn't, then I can understand Microsoft's reluctance to add this feature. They don't want to admit that they have "goofed" by forgetting it.

    However, it has now been 5 years and 2 new versions since this was first requested (I've been reading forums today), and one would think that Microsoft would have gotten the hint. Guess not.

    Reminds me of the old Bugs Bunny cartoons, when Daffy Duck is falling off a cliff, and Bugs says "I wonder if Daffy will remember he can fly...<splat>...Guess not!"

    *Sigh* Time to uninstall TFS and go back to VSS for a few more years. Or find a free SCC program that works a bit better. *Sigh*

    Monday, July 12, 2010 5:40 PM
  • As a build person, the Last checked in datetime tells me very quickly whether the files have been modfiied.

    Currently, the datemodified shown is the date when i perform the TF Get, which doesn't really help.

    Is there a patch available soon from Ms?

    Friday, February 18, 2011 12:57 PM
  • Also if there's an option to make files "Writeable" recursively, that'd be very handy.

    At the moment I have to do it manually via batch sripts.

    This is to enable my automated build process as i need to modify files for version numbering

    Friday, February 18, 2011 1:00 PM