[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Cross-device file move/rename [was: svn commit: r16293 - trunk/subversion/libsvn_wc]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-09-28 14:12:51 CEST

Erik Huelsmann wrote:
> On 9/28/05, Julian Foad <julianfoad@btopenworld.com> wrote:
>> [...] it's bad practice to
>>document our interface in terms of a third-party one unless it saves a
>>significant amount of duplication.)
> The UTF-8-ness should probably be added.

If you like, though I don't see the need if we document this interface without
reference to APR. Since it's inconsistently mentioned at the moment, it
doesn't matter either way. Some time I'll put a single note at the top of the
file and remove all the individual notes (perhaps excepting any where we still
document the Subversion function in terms of a corresponding APR function).

> The point of documenting by
> reference is that some of the APR documentation gives you a list of
> error returns.

Yes - that's covered by my "unless it saves a significant amount of
duplication", but that's not the case for the functions we're talking about
here (copy and rename).

>>If we do this (set read-write) before the copy, it simplifies the function
>>(removes the need for "goto") and allows an early return in this error case
>>(not that we should optimise for errors, but in this case the benefit is free).
> But if we do that, the read-only-ness won't be copied with the file in
> svn_io_copy_file(): I think it should copy attributes as complete as
> possible. That's why I did it this way.

That's a good point, and more important than my concerns.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 28 14:13:44 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.