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 :-). 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?
> 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.
If it were just that, I would agree (and no, I don't have any hard
data that it was an actual performance bottleneck, though it did clog
the output of strace quite a bit).
-K
---------------------------------------------------------------------
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:19:37 2003