On 25.12.2011 10:20, schame...@spinor.com wrote: > 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.
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
