RE: [PATCH]: new task: rename a file

["Kuiper, Arnout" <Ar...@nl.origin-it.com>]

> From: Thomas Haas [mailto:haas@softwired.ch]
> In our build we need to rename files, so here is the missing 
> rename task
> (using Copyfile as template, tnx duncan@x180.com):
> 
> <rename src="path/to/old.file" dest="path/to/new.file" 
> replace="yes|no"
> />
> 
> The file path/to/old.file is renamed to path/to/new.file.
> If src already exists and replace is true, the file is deleted first.
> If dst already exists and replace is false, the build halts.

+1 for me. When this is added, we have all basic file operations:
Delete, Copy and Rename.

Although I like to have the same syntax & behaviour as copyfile:
only replace when newer (so no replace attribute).

> 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.

My 2 cents,

  Arnout

Re: [PATCH]: new task: rename a file

[Thomas Haas <th...@softwired-inc.com>]

"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