[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Melski
Subject: Re: Using hash instead of timestamps to check for changes.
Date: Mon, 6 Apr 2015 15:17:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4

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.


Eric Melski
Chief Architect
Electric Cloud, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]