"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
