ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Haas <thomas.h...@softwired-inc.com>
Subject Re: [PATCH]: new task: rename a file
Date Tue, 07 Mar 2000 21:52:59 GMT


"Kuiper, Arnout" wrote:
[DELETED]

> > Copyfile does not copy files, if the destination is newer than the
> > source. I was a little bit surprised of this non obvious implicit
> > behaviour of Copyfile. I would like to understand the rational behind
> > the feature and ask, if it can be turned into an option. Of course I
> > would like to have the feature turned of by default, but I am
> > biased on
> > this. Copyfile would look like this:
> >
> > <copyfile src="path/to/old.file" dest="path/to/new.file"
> > filtering="yes|no" skipnewer="yes|no"  />
>
> The rationale behind the implicit check for newer files, is that in 99.9%
> of all cases you don't want to copy a file again, when it is there already.
> A check on the date is a pretty good indicator that a file has not been
> changed. When rebuilding your project, this can save a huge amount of time.
> Only in exceptional cases you want to overwrite a file with an older one.
> In these rare situations, you can better use a delete in combination with
> a copyfile. I like the way it is done now.

First, thanks for the feedback.
I agree, that copy and rename tasks should have the same semantic. My problem
was, that prior to looking at the code of copyfile, I did not know, that new
files are skipped and I did not expect this behaviour. I would not expect a
rename task to behave this way. As you stated, I very know well how usefull
this feature can be in a build description. I wanted to make it explicit and I
am offering to patch the copy tasks accordingly, so both will have the same
semantic.

The situation is somehow the same as with the javac task, which also copied
files. I am glad this has been corrected.

- tom



Mime
View raw message