[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1222522 - /subversion/branches/1.7.x/STATUS

From: Branko Čibej <brane_at_apache.org>
Date: Sun, 25 Dec 2011 11:00:26 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.