> From: kfogel@collab.net <kfogel@collab.net>
> Date: 20 Oct 2003 13:45:04 -0500
> I'm not sure we're confident enough about that patch (that it solves
> the problem) to put it in mainline Subversion. It would suck to have
> something so ugly in the code and yet *still* have the problem --
> whereas no one minds so much if it's just an experimental workaround.
I strongly believe that D.J.'s change should be installed now:
1. If it isn't sufficient then much more radical changes will have to be
considered, such as redoing the entire write-temp-rename-permanent
approach. It's important to know now if the change isn't sufficient
and the only way to find out is to stick it in the distribution.
Subversion is still beta after all.
2. It's critical to get past this and know if there are other
problems. In my case the concurrency failures I see are much less
frequent than rename failures. Rename failures may be what halts
90% of test runs but it's that other 10%, whose cause and
work-arounds are unknown to me, that are worrisome.
Other points:
3. This is a low-risk change in that no non-error scenario is
affected, and
4. The change, if unsuccessful, leaves things no worse than they were
without the change.
Looping on a rename or delete seems bizarre to those with a unix
background but it is apparently considered best-practice in the
Windows world, infested as it is with anti-virus software and the
Win32 implicit-lock metaphor.
I believe two other changes should be made:
5. The error text for a delete and rename should be changed so that
developers can tell from the error message if it is pre-change or
post-change code that failed.
6. There should be some record kept of how often an initial delete or
rename failed, how many loop iterations were needed to succeed, and
how many times the failure was permanent. This could be written to a
static log file, the Windows Event Log, or a scorecard (see below).
Logging shows me that looping on the rename does fix the problem.
The question is if it is sufficient to fix every instance of the
problem.
> Wish we had a better sense of how often users run into the problem...
I like to keep summary scoreboards or scorecards for this sort of
thing. Users whose scorecard indicated an unusually large number of
"interesting" errors could be asked "Please consider sending ..." to
send their scorecard to developers.
For this issue there might be a scorecard box for the number of times
an initial rename or delete failed and the number of retries before it
succeeded, and especially how often the maximum retries compiled in
were unsuccessful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 26 16:20:07 2003