On 2011-12-25 06:37, Branko Čibej wrote:
On 24.12.2011 23:03, schame...@spinor.com wrote:
On 24.12.2011 11:54, Stefan Küng wrote:
maybe you have a 10GHz machine on your hands. But most people don't.
Using RPC for every svn API call would bring every machine down easily.
Oh come now. We're not talking about some Enterprise XYZ RPC thingamabob
that does everything through a distributed transaction manager. Local
IPC-based RPC isn't all that slow. But that's beside the point.
My point is that (a) there are alternatives, and (b) there is no way
under the sun to make the Subversion libraries 100% crash-safe,
It is a very, very, very broken design if a library can abort.
Even "only" crashing a plugin is not acceptable.
It's not a matter of design. I agree that abort-like constructs are
being abused in the libraries, and that's an implementation issue, not a
design issue. But no design in the world is going to avoid external
circumstances. There are always going to be cases where you have to
decide between aborting, or risking data corruption (or worse). Which
would you pick?
Definitely data corruption, because (except for bugs) every data
corruption is continuable and somehow recoverable,
e.g. in the worst case by the user re-checking out the wc.
Having one broken wc on your disk is definitely better
than crashing the whole explorer and *all* other running operations
with it.
In our (much bigger) software every error is recoverable
without memory leaks (except for bugs we try to fix),
even broken low-level serialization streams.
In the worst case you cannot use some particular data/project file
anymore, but the app should never crash, you should always be open
a different project for instance.
Folker
