It's all about the answers!

Ask a question

Preserve File timestamps when accepting file in RTC build

Shinobu Ishida (1371915) | asked Jun 21 '18, 4:22 a.m.
edited Jun 21 '18, 11:11 a.m. by David Lafreniere (4.8k7)

I am using RTC 6.0.3.
I know when loading files using RTC 6.0.3 client, the user can now specify that they would like the timestamp from the file in the repository to be used as the timestamp on disk.

Can I preserve the timestamp when accepting and loading files from the stream into the build workspace
by using the "Source Control" tab of the build definition, as loading in the Eclipse client?


Accepted answer

permanent link
David Lafreniere (4.8k7) | answered Jun 21 '18, 11:11 a.m.
In RTC 6.0.3 the ability to load and preserve timestamps was added in:

You need to use the build property: 'team.scm.preserveFileTimestamps = true'
Shinobu Ishida selected this answer as the correct answer

Shinobu Ishida commented Jun 21 '18, 8:41 p.m.

Thanks, David!

Shinobu Ishida commented Jul 31 '18, 10:24 p.m.

I set 'team.scm.preserveFileTimestamps = true' to the build property.

All time stamps were retained in the initial build loading. However, the time stamp is not retained for a accepted file while repeating the build.
In the acceptance option of the build definition, "Accept the latest change before loading" is selected, and the directory in the build workspace has not been deleted at the time of loading.

Any Help is appreciated.

David Lafreniere commented Aug 01 '18, 10:58 a.m.
Feel free to look at the following work item and see if it is similar:

You can comment on that one, or even open a new work item (since that one was specifically about the Shell client, and not the Build).

Shinobu Ishida commented Aug 02 '18, 4:18 a.m. | edited Aug 02 '18, 4:19 a.m.

Thanks, David. I understand this is as designed!

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.