"Peter Kahn" <pkahn@connected.com> writes:
> Any ideas on what is a reasonable course of action? I was going to
> attempt to replicate the situation on a backup copy of my database, but
> that does bring in many variables because I cannot get back to the same
> state that the db was in prior to the issue. My other possibility is to
> write an additional pre-commit hook to analyze the check in prior to
> processing and record this information in a log.
Well, that would be very helpful for us in debugging, if you spot a
pattern.
If you just want the problem solved, I suggest switching to FSFS.
Subversion's use of Berkeley DB is not quite as the Berkeley docs
recommend (I phrase it this way because I don't want to see
Berkeley/Sleepycat blamed for what is really Subversion's problem).
The bugs are frustratingly idiosyncratic: some people never get them,
others get them once in a blue moon, some (like you) apparently get
them on a regular basis. For people in that last category, FSFS is
probably the way to go.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 13 19:02:29 2005