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

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

Buck Hodges — Mon, 23 May 2011 20:17:43 GMT

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

Buck

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

Edward Williams — Mon, 23 May 2011 20:08:28 GMT

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?

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

wewilder — Thu, 05 Aug 2010 13:52:57 GMT

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.

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

wewilder — Wed, 04 Aug 2010 19:50:36 GMT

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.

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

John Hardin — Wed, 04 Aug 2010 17:41:26 GMT

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

Buck:

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.

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

Buck Hodges — Fri, 25 Jun 2010 13:28:38 GMT

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.

Buck

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

John Hardin — Tue, 22 Jun 2010 17:37:30 GMT

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.

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

John Moreno — Sat, 15 Aug 2009 03:55:26 GMT

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.

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

Buck Hodges — Mon, 01 Oct 2007 19:46:41 GMT

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.

Buck

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

burton — Mon, 01 Oct 2007 18:03:07 GMT

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?