On 04/11/2015 08:38 AM, Enrico Weigelt, metux IT consult wrote:
On 07.04.2015 00:17, Eric Melski wrote:
Hi,
This problem is relatively common when using an SCM system that
preserves *checkin* time on files rather than *checkout* time.
I'd consider that a misbehavious of the SCM (IMHO, that's the reason
why Git does not track the mtime). From the filesystem perspective,
the mtime represents the time when the actual file was changed in the
filesystem. So, resetting the mtime from some SCM repo actually is
tricking the filesystem - pretty obvious that the mtime then isn't
reliable anymore.
It doesn't necessarily require "resetting" or "manipulating" the mtime
at all. ClearCase has its own filesystem, MVFS, which simply behaves
the way I described. In any case, it's not an utterly irrational
position to consider the last modification time of a file tracked by the
version control system to be the time that a new revision of the file
was created. That *is* the last modification time, after all.
However, this is not the place for this type of philosophical debate.
The question at hand is whether or not make would benefit from a
non-timestamp-based notion of "up-to-dateness", and the answer seems to
be clearly yes, for this and other reasons mentioned elsewhere in this
thread.
Regards,
Eric Melski
Chief Architect
Electric Cloud, Inc.
http://blog.melski.net/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
