Quoting kfogel@collab.net:
> Luke Blanshard <luke@blanshard.us> writes:
> > Is there ever a time when you want remove_file_if_present to fail on
> > Windows because the permissions are wrong? In other words, why not
> > simply rewrite remove_file_if_present to set the file read-write
> > before removing it, instead of repeating the same logic everywhere?
> > Better yet, only do this extra step on systems that actually require
> > it -- if you can get APR to encapsulate this.
>
> We used to have similar logic in svn_io_removed_file() too, but it
> turned out it was masking some inconsistent assumptions in the calling
> code -- a lot of the time, the file was already writeable, and we were
> wasting time setting it so.
>
> After that, we made a policy that the low-level removal functions
> would always assume that their targets were writeable, and callers
> would be responsible for ensuring this.
Was this policy discussed on the list? I must've missed that thread...
> While this decision hasn't
> made its way to all the code yet (see issue 1279), I think it's a good
> way to go...
It's also impossible to test ATM, for two reasons: a) the Windows build doesn't,
which means that nobody's running tests on Windows; b) our test coverage isn't
good enough.
One thing I never saw was performance test output pointing its finger of blame
at that chmod. Has anyone seen any difference in the speed of the client? If
not, then I can't understand why you're wasting time on this, breaking things
left and right, without a single bit of hard data to go on.
BTW, that chmod is only necessary on Windows, never on Unix. So if you want to
speed things up for Unix users, revert all these changes and put an "#ifdef
SVN_WIN32" around the chmod in svn_io_remove_file. Or write an
"svn_adm_remove_file" and use that wherever we're deleting files in the .svn
area. Or just stop making those files read-only (huh, another waste of time,
since 99% of the time users won't fiddle with those files).
Sorry if I seem to have blown my top a bit, but this fiddling with a chmod looks
just as well thought out as any of the myriad hare-brained schemes to "speed up
the client" that we've so gleefuly shot down in the past.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 4 12:26:40 2003