On 25.12.2011 10:20, schamel23_at_spinor.com wrote:
> 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.
That's an interesting point of view. You are of course assuming that
such data corruption is easily detectable. And that it doesn't waste
days of work.
-- Brane
Received on 2011-12-25 11:01:02 CET