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 withModificationas 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 toCurrentand there’s no option in the UI for changing this.How can I make TFS-VC useModificationdate instead?
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,
Martin.
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,
Martin
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.
