"Bill Tutt" <rassilon@lyra.org> writes:
> > > No, we know (or think we can figure out) a way to unwedge a *known
> > > wedged* repository.
> > >
> > > The think is, that's the same as lock-stealing, if you're not
> > > sure that no one else is using it.
> >
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=176926
> >
> > And there were more threads on this subject IIRC. One specifically
> > dealt with the situation you sketch.
> >
>
> In fact, let me be even clearer in case what I've been saying hasn't
> come across correctly. The issue outlined by the URL that Sander
> mentioned above IMNSHO is a 1.0 ship stopping bug.
>
> We must be atomic, we must be consistent, we must be isolated, and we
> must be durable. Additionally, we must also be reliable. There is no
> compromise possible. Ctrl-C is but the smallest of the annoying problems
> that data stores encounter when trying to ensure durability and
> reliability. There are hundreds of others.
Maybe I'm missing something, but neither the email referenced above
nor the Berkeley DB documentation it refers to, appear to solve the
lock-stealing problem. The suggestion, to always run recover when
opening the DB is not valid. It requires the Subversion clients to be
either "a single, usually multithreaded, process" or "a set of
cooperating processes" and neither of those apply. The Subversion
clients are a set of independent processes.
It boils down to "the Berkeley DB library itself cannot determine
whether recovery is required" and so neither can a single Subversion
client. To make the decision to run recovery requires clients either
to communicate and interact, or to assume that they are the only
client.
It looks like compromise is required ;-)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 19 02:26:08 2002