Hi all, 2009/4/24 Steve Appling <[email protected]>
> > > Hans Dockter wrote: > >> >> On Apr 23, 2009, at 1:03 PM, Tom Eyckmans wrote: >> >> >>> >>> 2009/4/23 Steve Appling <[email protected]> >>> >>> >>> Tom Eyckmans wrote: >>> Hi Steve, >>> >>> The previous message got rejected because of it's size so I have put the >>> test jar here http://www.box.net/shared/rjfyath7lb hope that works. >>> >>> clipped ... >>> >>> >>> True. Could you perform a speed test with the jar file in attachment? >>> >>> just execute it like so: >>> >>> java -jar changedetection-0.1 dirOne dirTwo dirThree >>> >>> Do you really need to include the file content, or can you trust >>> the OS to update last modified date? >>> Not sure, but I know there is a force method on randomaccessfile >>> that allows to only force the content or both content and >>> metadata to be flushed. Thats why I included the content because >>> this allows the modified date not to be updated even when the >>> content has changed. >>> >>> I know it is possible to do this, but unusual in normal development. >>> >> >> We have run into timestamp issues with svn revert: >> http://jira.codehaus.org/browse/GRADLE-311 >> >> So having a timestamp only approach might be too fragile. We probably >> should provide an option to our users between a timestamp and hash based >> change detection approach. >> >> - Hans >> > > Path + timestamp + file size might be a little more reliable (and still > much faster than including the content). > Got the change detection logic I had in mind working (it isn't polished yet tho), you can find it on my changedetection branch on github ( http://github.com/teyckmans/gradle/tree/changedetection) I think it will perform nicely (hashing is multithreaded, new/old state comparing isn't (if this is needed I'll have to do some deep thinking)). Steve if you want to perform a test there is a ChangeDetecter main class that you can modify for testing in the org.gradle.api.changedetection package. I hope you all like it, I think it is the very efficient and because of that rather complex code so I'll add some documentation to it in the coming days. > > > -- > Steve Appling > Automated Logic Research Team > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
