Tom Eyckmans wrote:
2009/5/1 Tom Eyckmans <[email protected] <mailto:[email protected]>>
Hi all,
2009/4/24 Steve Appling <[email protected]
<mailto:[email protected]>>
Hans Dockter wrote:
On Apr 23, 2009, at 1:03 PM, Tom Eyckmans wrote:
2009/4/23 Steve Appling <[email protected]
<mailto:[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.
Great, I'll try to play with this some this afternoon.
FYI - it wouldn't compile as is in your branch for me. I had to add
"commons-codec:commons-codec:1...@jar" to the compile configuration to get it to
build.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
