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 ?
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
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:
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
(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 ?
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.
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.
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:
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.
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.
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.
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.
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:
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 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.
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
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..
this system is not built on 'files', it is built on 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.
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.
rtc doesn't save files, only changes. it reconstructs the file on the fly from the accumulated changes, so the original file date isn't anywhere.
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.
However, there are many that have requested this feature. There is discussion recorded in work item 83718. There was an attempt at an implementation but an issue was discovered during development described in work item 159043. It's not a trivial problem and the expected solution negatively affects build use cases that rely on the timestamps to detect what's changed. I'm not sure everyone is aware of this when they want this feature.