kfogel@collab.net wrote:
>brane@xbc.nu writes:
>
>
>>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.
>>
>>
>
>"Left and right" is a bit much :-).
>
Yeah. I tend to exaggerate a bit every now and then. :-)
> I did run the test suite on Unix;
>I wasn't aware that Windows had different semantics w.r.t. file
>removal & perms than Unix has.
>
>My primary motivation wasn't for performance reasons, it was because I
>felt that our underlying (svn_io_) file removal mechanism shouldn't be
>doing a chmod by default, because that might someday blow away
>something that shouldn't be blown away. Instead, it should be the
>caller's responsibility to know that something is ready to be removed.
>
>Another solution is to have a `force' flag, as you mentioned, though I
>still feel that callers working in the .svn/ area ought to *know*
>whether something needs to be chmod'd or not.
>
>I'm sorry I haven't had a chance to deal with issue #1279 yet. I've
>felt the urgency somewhat lessened becuase the Win32 build is broken
>(?), and been trying to avoid getting distracted from cvs2svn, which
>we really need to get finished. I can revert the relevant portion of
>revision 5663, to get a quick fix if that's needed right away, but
>IMHO a real solution requires identifying the problematic callers and
>either passing a `force' flag or having them manually set the target
>read/write.
>
>What do you think is the best course right now?
>
I suggested adding another function (either to adm_files.c or io.c) that
deals specifically with files in .svn. Mike is right; if a caller
doesn't know the file to be deleted is in the .svn area, then something
is wrong with the caller. Unfortunately, that still means every call to
svn_io_remove_file (and rename, too) has to be checked and fixed.
For a minute there I wondered if we shouldn't just stop making the admin
files read-only, then I rememberd it's not just the text bases (which we
have checksums for), but also the prop files, which aren't checksummed.
Here's what I'd do: First, I'd instrument svn_io_remove_file to check if
the file is read-only, and complain (to a log file?) if it's not. Then
I'd run the test suite, fixing the calls that produce a warning until
svn_io_remove_file is quiet.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 5 19:56:31 2003