On 27/03/2012, at 11:04 PM, Daz DeBoer wrote: > > On 27 March 2012 05:43, Luke Daley <[email protected]> wrote: > > On 27/03/2012, at 6:04 AM, Szczepan Faber wrote: >> In short, relative comparison of timestamps is always a bad idea. We should >> be treating them as opaque identifiers (i.e. can only check for equality) >> and never on their own (i.e. include length as well). >> >> I'm sold. > > Interestingly, I hit a quirk of this approach testing my changes. > > We have an integration test that publishes a module then changes it instantly > (in < 1 sec). HTTP dates have second fidelity. The test was changing the > content, without changing the file length and the modification date > difference was < 1 sec. A joy to debug, obvious in hindsight. > > Ouch. The test method publishWithChangedContent() should probably change the > content length, I guess.
Or maybe it shouldn't. Changing the content without changing the length is not completely unusual (e.g. a pom artefact generally doesn't change size when you publish a snapshot), and it's kind of nice that the fixture is a little unexpected in its behaviour. > In the real world I'm not sure if we need to differentiate resources > published with the same content length in the same second… timestamp + length has been a pretty reliable predictor for a changed file in the task up-to-date checking. I think this should be pretty reliable for http resources, too. Particularly if combined with etags. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
