files loaded from source control do not preserve modify date
Hello. I have noticed that when I load files from RTC source control (2.0.0.2 client and server) onto a machine, that the loaded files show the date at which the load is done. The true date that the files were last modified is not preserved.
What would be more useful is to preserve the the date that the files was last modified, which would be the (operating system) date that each file showed (on disk) when it was added or updated into source control. In RTC, a date is shown in the history history pane, this is the date of the change transaction, which is usually close to this last modiified date of each file, yet this date is also not used when the file is loaded out onto disk. I looked at the load options, and do not see an option to preserve the last mofidied date on load. Is there a mechanism to preserve last modified date, or bvarring that, last transaction date, on load ? |
7 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Mar 11 '10, 9:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This is currently not supported.
To explore the ramifications of this a bit ... what would you expect to happen if you "suspended" a change set in that workspace? To be consistent with the rule that "the mod date of a file is its change-set creation date", the mod date on a reverted file would have to be changed to an earlier date. But then date-based build systems (like "make") would fail to recompile the reverted files (except for the few build systems like clearmake, which are designed to handle files changing both forward and backward in time). Cheers, Geoff rick.patterson.jazz.net wrote: Hello. I have noticed that when I load files from RTC source control |
Hi.
File modification dates in RTC would be associated with the time a file was last modified. It is the date of the file as seen on disk when a change set is made, and not the time of the changeset being processed or committed. A changeset may be made with a set of files at all different dates. If a changeset is suspended, the changed dates (for each file) associated with that change set would also be suspended. If a file is reverted to an earlier reversion, then the earlier date would be applied to the file. The modification date should be considered part of the "data" of the file. It is part of the data after all, the metadata, no different than other attributes of the files, such as the field permissions on UNIX, or other properties on other OSes. Another way to think of it: If the source control system were to be implemented by just making a complete copy of each version of the file, by backing it up to some kind of archive directory on a server, using a copy or archive command that (normally) preserves date, then whenever that file is restored, it would be restored with whatever date is on the backed-up file. The fact that the SCM system might be more efficient in storing file versions by only keeping deltas should be transparent, each delta should have the modification data of the file associated with it. Whether the file is restored from the SCM system from a backup copy, or re-constituted from deltas, should be indistinguishable to the end user. When I load files from a change set, I should get the dates on each file as they were on disk at the time the changeset was done. If I load files from a changeset from a year ago, then I would expect to see dates of the files from at least a year ago. It would be required of the user to ensure this does not mess up his build environment. Reverting a source file to an older version, without deleteing the associated object file, and expecting the make to rebuild the source would be a user error. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Mar 12 '10, 11:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
What is missing is the motivation to have the date stamps act this way.
In particular, the benefits would need to outweigh the cost of breaking the date-stamp dependency behavior of most make-style tools. Requiring users to investigate all the change sets to determine which files will have their date stamps rolled back, and then figure out all the derived files that would need to be deleted (and the primary point of make is to allow users to not know those dependencies). Cheers, Geoff rick.patterson.jazz.net wrote: Hi. |
Hi.
I seem to be missing something, I do not see what the date-time dependency of make has to do with this, but if there is a connection with make to be made, I can only think preserving dates is more beneficial than not preserving dates. For example, If I fetch out a bunch of code fom a year ago into a new (clean) area, and do a make, then the make will rebuild the code whether it has today's dates or a year agos' dates on them, (as the dependent objects are not there in a clean directory). If I have an existing build structure from a year ago, (objects and code both in the structure and dated a year ago)and re-fetch the code, and only the code that has been changed is fetched, then the make will only reubild what it should, which would be the changed code that is fetched. If all the code is fetched with new dates, and there are old objects then code will be rebuilt needlessly. My basic point is the date shown on files should reflect the last time the files were modified. This way it does not matter when they were fetched. If I compare a set of files fetched today with the same files fetched a week ago, and they are indeed the same files, then the dates would be the same as well. Copy and archive commands preserve these dates for this reason. Source control is just another method method of archiving. If I arhive a set of files today, and re-extract them to a different directory, they are still the same files and show the same dates. Showing different dates implies they are not the same files, and then one has to do more comparisons before one can see that they are the same. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Mar 14 '10, 4:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This is the make-based scenario:
I have a file area (sandbox) created by Team Concert. I run "make" to build my derived objects. I "suspend" some number of change sets (or perhaps "replace" a component with an earlier baseline). I then rerun "make" to re-build my derived objects. With the current behavior, everything is fine, because the dates on the files correctly reflect the fact that they have been updated (from the perspective of that file area). Every changed file gets the current date, making the derived files in the file area older (and therefore out-of-date) wrt those input files. Make re-builds only those files whose dependents have changed (as any good build system should do), thus rebuilding only the derived files that need to be re-built. With the proposed behavior (rolling the dates back to the "creation date" of the newly selected versions), when I re-run "make", it says that all the derived files are still valid (because the date on the derived file is later than the date on any of its input files). But that is of course false ... those derived files are no longer valid, but the date-based make doesn't know that, because it expects that whenever a file changes, its modification date will increase. Cheers, Geoff rick.patterson.jazz.net wrote: Hi. |
I'm having the same issue. Has anything changed in regards to file date stamps? When I load a repository to my local sanbox, all the files get a new timestamp. Is there a way to keep them with their original timestamps?
|
I see this question hasn't been updated in a while, but the problem is still here. Any news on this? Is this something that was (or will be) addressed in a later version of RTC?
Comments
sam detweiler
commented Apr 03 '14, 8:04 p.m.
no.. and why do you care? the change sets document the changes, not the date/time of the constructed file. the file date on your machine isn't used in any way on submission of changes..
We care in the situation when builds are done, and source files are part of the builds. Some builds contain some or many source files or even possibly are completely source files - JavaScript, python, xml files, documentation, etc. In this case, the relevant dates are the date of the last modification, and not the time of when the files are fetched from source control. After a build is done , and I wish to compare to a previous build of these source files, all the files show as changed, yet maybe only a couple of files might have really changed. I have to use tool such as Beyond Compare to see what has actually changed. If dates were presrved, I could have an idea of what changed just by looking at the dates.
sam detweiler
commented Apr 03 '14, 11:34 p.m.
given that use case I think there are other approaches (comparing baselines or snapshots) that give you the same answer without looking at the file dates.
For Rick's case of determining if changes were made, it sounds like you want a comparison since the last build to show the list of changed files. This would be accomplished using build snapshots. I'm not really sure why you need dates for this kind of comparison.
|
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.