On Tue, Dec 14, 2010 at 03:57:37PM -0500, C. Michael Pilato wrote:
> On 12/14/2010 01:47 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, Dec 14, 2010 at 12:14:00 -0500:
> >> Is there a case to be made for allowing 'svnadmin load' to, upon specific
> >> request by the user (via a new --disable-prop-validation flag or something),
> >
> > Yes.
> >
> > We've had many reports of svnsync aborting over non-canonical revprop
> > values after we started enforcing that in libsvn_repos during commits.
> > Every one of those reports represents a broken repository. Adding such
> > a flag will allow the admins of said repositories to dump|load their
> > repositories without first fixing all historical revprops.
>
> It's not just revprops that are being validated by the 'svnadmin load'
> process now -- it's node properties (svn:ignore, etc.), too. I can
> certainly see the case for allowing a *technically* sane dump to be loaded
> without error, even if some of the contents thereof aren't up to our
> strictest standards.
>
> Now I find myself questioning the whole change. Do I move forward in this
> fashion, with 'svnadmin load' defaulting to prop validation w/ errors but
> offering a --disable-prop-validation flag? Should the defaults be reversed?
> What about 'svnrdump' -- does it need the same flexibility (I don't think
> this is actually possible, by the way)? Do I back off a bit and make
> nothing error, but instead should print warning notifications during the
> load process whenever a bogus property is about to be loaded?
I'd say make it error, provide a by-pass flag for those who need it,
and document the by-pass flag in the error message.
Erroring out makes these kinds problems much more likely to be noticed
and fixed.
Stefan
Received on 2010-12-14 23:08:07 CET