[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.)
Received on Mon Jul 10 10:58:16 2006