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.
2009/4/23 Tom Eyckmans <[email protected]> > Hi Steve, > > 2009/4/23 Steve Appling <[email protected]> > >> >> >> Tom Eyckmans wrote: >> >>> Hi all, >>> >>> Just performed a test to detect changes so we can decide whether >>> something has changed in a source / resource directory. >>> >>> What I tested was the following compute SHA of a directory based on all >>> files in that directory: >>> >>> absolute file path + last modified date + file content. >>> >>> On the Gradle source / resource directories this comes down to the >>> following: >>> >>> gradle-0.5.2\src\main\groovy : 7a5160bffe95f236dfceb2ac3d1609a747eb132c >>> gradle-0.5.2\src\main\resources : >>> de37bc2b812b9116b400e3708a0a19524fb2aed8 >>> gradle-0.5.2\src\test\groovy : 7f49b3276ef4b60b42d5880dad4367470bc64a75 >>> gradle-0.5.2\src\test\resources : >>> 7915e5a3449a5584dbafc542a3f9abda687da783 >>> >>> time taken: PT0.797S >>> >>> I think this is fast enough. >>> >> >> That's only about 612 files, which isn't that big. > > 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. > > >> Seems better to just use absolute file path + last modified date. >> >> -- >> Steve Appling >> Automated Logic Research Team >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
