These are good ideas, but I think you're solving the problem in the
wrong place. In the example Bruce posted, the problem was in the ZIP
"file-system" rather than FAT. A single-property solution wouldn't
help there -- it would solve the 2sec granularity for ZIP at the
expense of reduced granulari
On Tue, 08 Mar 2005, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> Steve Loughran wrote:
>
>>
>> 1. we could have a property "ant.filesys.granularity" which can be
>> set to something in a build.properties or on the command line. if
>> unset, you get the default..
>
> I don't have a problem with th
Xxx Yyy wrote:
I disagree with the measurements here. The granularity default should
not be based on popularity of FS or current usage of ant. Ant must
work in a predictable, reliable manner. And maintain function from
release to release. As ant tries to get intelligent and make
assumptions on
Steve Loughran wrote:
1. we could have a property "ant.filesys.granularity" which can be set
to something in a build.properties or on the command line. if unset,
you get the default..
I don't have a problem with this, but I know the general reaction is "No
Magic Properties".
2. we could have a
I had yet another thought,
why don't we assume (unless specified otherwise) that the filesystem
timestamp granularity of all involved filesystems is the same (we
currently already do, and tie some pretty strange conclusions to that fact).
That way we should be able to not take into account the gr
I disagree with the measurements here. The granularity default should
not be based on popularity of FS or current usage of ant. Ant must
work in a predictable, reliable manner. And maintain function from
release to release. As ant tries to get intelligent and make
assumptions on its own, it is
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> I was thinking about this.
>
> the original example may have been inherently
> brittle to change - a
> sufficiently fast transform could have taken 0
> seconds, but the fact
> is, our granularity logic has broken the build on
> windows,
Bruce Atherton wrote:
Xxx Yyy wrote:
Thanks for your consideration. I think you are testing the wrong thing
-- an OS test is not a substitute for FS test.
That is true, but there is no FS test. This code is not trying to be an
FS test, it is trying to be smart about guessing a default value using
Xxx Yyy wrote:
Thanks for your consideration. I think you are testing the wrong thing
-- an OS test is not a substitute for FS test.
That is true, but there is no FS test. This code is not trying to be an
FS test, it is trying to be smart about guessing a default value using
whatever information
Thanks for your consideration. I think you are testing the wrong thing
-- an OS test is not a substitute for FS test. This whole thing has a
"bad smell" to it because the granularity is worming its way into Unix
special cases, per your note, and ANT users now need to compensate for
the cases at t
Phil Weighill-Smith wrote:
Won't argue with your comment in general, but Xxx Yyy wrote:
which seems to be a case where overwrite is appropriate.
touche!
Peter
Phil :n)
On Tue, 2005-03-08 at 16:44, Peter Reilly wrote:
Phil Weighill-Smith wrote:
An alternative, and far more
Won't argue with your comment in general, but Xxx Yyy wrote:
>>
>>
>>
which seems to be a case where overwrite is appropriate.
Phil :n)
On Tue, 2005-03-08 at 16:44, Peter Reilly wrote:
> Phil Weighill-Smith wrote:
>
> >An alternative, and far more portable work-around is to just use
Xxx Yyy wrote:
I looked, but didn't find any discussion on the new granularity
FileUtils.getFileTimestampGranularity. This is messing up my builds
big-time.
If you are on Windows and you run two COPY operations within two
seconds of each other, the second COPY will be skipped.
Phil Weighill-Smith wrote:
An alternative, and far more portable work-around is to just use the
overwrite attribute on the second copy task.
I think that this build file is just an example to show the
problem, so this work-around may not be suitable for the real build file.
This is the correct w
An alternative, and far more portable work-around is to just use the
overwrite attribute on the second copy task.
Phil :n)
On Tue, 2005-03-08 at 16:11, Xxx Yyy wrote:
> I looked, but didn't find any discussion on the new granularity
> FileUtils.getFileTimestampGranularity. This is messing up my
I looked, but didn't find any discussion on the new granularity
FileUtils.getFileTimestampGranularity. This is messing up my builds
big-time.
If you are on Windows and you run two COPY operations within two
seconds of each other, the second COPY will be skipped.
16 matches
Mail list logo
