Re: Using hash instead of timestamps to check for changes.

[Eric Melski]

On 04/04/2015 11:38 AM, Tim Murphy wrote:
>     >    My thinking is that the timestamp is in fact an overly conservative
>     >   test.  We never have the case that the timestamp indicates something
>     >   *has not* been changed when in fact it has (i.e. we always build if
>     >   something has changed),
>
>     That's interesting, because in my experience the main reason people are
>     upset about timestamps these days is the exact opposite: with the
>     increase in capabilities of systems, in particular larger build servers,
>     it is possible to have situations where targets are updated too quickly
>     to reliably determine out-of-date-ness based solely on timestamps.
>
>
> That may be a use case but I've not experienced it more than once, IIRC,
> but I've often  experienced things which are automatically generated or
> copied and which
> trigger huge rebuilds for no ultimate purpose.

This problem is relatively common when using an SCM system that 
preserves *checkin* time on files rather than *checkout* time. 
ClearCase does this in various configurations, and Perforce will if your 
client spec has "modtime" set.  I'm sure other SCM systems can be setup 
this way too.

In such environments, the timestamp on a file may not change *enough* 
even when the content has changed.  For example, suppose the following:

1.  I have file foo.c with time A.
2.  My teammate modifies foo.c and checks in at time B.
3.  I build in my workspace, without sync'ing, generating foo.c with time C.
4.  I sync my workspace, updating foo.c but leaving it with time B.
5.  I try to rebuild but foo.o is not updated because C is later than B.

ClearCase's "clearmake" utility handles this, of course.  The problem 
occurs frequently enough that we added a feature to Electric Make called 
the "ledger" expressly to allow us to notice this type of out-of-dateness.

Regards,

Eric Melski
Chief Architect
Electric Cloud, Inc.