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
