On 2011-12-25 06:37, Branko Čibej wrote:
> On 24.12.2011 23:03, schamel23_at_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
Received on 2011-12-25 10:20:52 CET