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).
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
