2009/5/1 Tom Eyckmans <[email protected]> > 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)). >
new/old state comparison is now also multithreaded > > > 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 >> >> >> >
