I've been right through the SVN coding practice doc and it is all very good
stuff. Like you say subversion detect errors rather than crashes and from
that pov it is very solid.
I this is off topic is I'll just clear it up and then we should drop it.
>>your very simple rule of thumb mandates that Subversion _always_ attempt
to
>>recover from _all_ possible ways to corrupt a working copy.
This just depends who your target market is. In my experience I have found
that writing tools for non technical people you really do need to take that
approach. I have also found that staff who are not used to this approach are
as exasperated as you are, but as we do not have to options of rejecting
bugs like you do the approach saves time in the long run.
As SVN is a tool for programmers by programmers I can understand you pov,
although I don't agree with it.
rich
-----Original Message-----
From: Peter Samuelson [mailto:peter@p12n.org]
Sent: 10 July 2006 09:58
To: Taylor, Richard
Cc: dev@subversion.tigris.org
Subject: Re: svn cleanup bug
[Richard Taylor]
> I am a professional programmer and I hear all kinds of excuses from
> staff why they shouldn't have to error check data or recover from
> corrupt data.
And you accuse Garrett of widening the scope! This is not about error
checking. Subversion is doing error checking, that's why you noticed
the problem.
> We have to strive to make software as robust as possible. We have a
> very simple rule of thumb, "if it stop in your code it's your fault",
> even if it's a result of bad input.
Despite your earlier protestation, your very simple rule of thumb
mandates that Subversion _always_ attempt to recover from _all_
possible ways to corrupt a working copy. (If this isn't what you mean,
you should find a better rule of thumb.)
There is your approach, which is to do everything possible to work
around bad input, regardless of how hard this is or how sure of the
results you can be - and then there is the practical approach, which is
to flag errors, safely abort when a "should never happen" condition
happens, and, if necessary, provide a "data recovery" process to deal
with cases of corruption which can reasonably be dealt with.
There are lots of ways to break a working copy, if you allow processes
outside Subversion to add, remove or edit files in .svn/. If you'd
like to contribute a script to "recover" a broken working copy, I am
sure the Subversion developers would be happy to consider adding it to
the 'contrib/client-side/' directory of the distribution. (Whether
they actually accept the script will depend on your license terms and
code quality.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 11:57:27 2006