We seem to have consensus that enabling verify_as_revision_before_current_plus_plus()
in production should be safe. It seems like it should be a useful extra protection against bug-induced repository corruption. For users who have experienced repository corruption and suspect it is bug-induced, or who are more concerned about this than about maximizing commit throughput, enabling such code would seem to be prudent.
We have long suggested running 'svnadmin verify' on each committed revision. Is it because of a policy that we currently ship a configuration which by default doesn't do this, favouring speed at the expense of consistency checking? Or, when such checking is technically available, should our policy be to provide administrative choice?
As I mentioned, one WANdisco customer recently experienced bug-induced corruption twice in quick succession, and we were unable to isolate the cause. I advised WANdisco to make a special build, enabling this, for this customer. However, it is unsatisfactory to ship different builds depending on whether a customer currently prefers more speed or more reliability.
While I don't support adding too many config knobs, a choice like this is something that the software cannot reasonably make by itself, so this is a case where a new knob is justified, in my opinion.
Alternatively, given that Subversion's number one priority is supposed to be reliability, why would we not enable this verification permanently? The argument would, I suppose, be that it is unnecessary. Yet we don't have convincing data to support that. Does anyone support enabling this permanently? I ask mainly to make us think about it. The easy answer is we don't want to reduce commit speed this much (how much?) without evidence of need.
Another reason to make it configurable is that then if a user finds corruption, like this customer did, they could quickly enable it and repeat a similar commit and discover whether it does in fact protect against that use case. In the case of the customer mentioned above, we lost the opportunity to do that because they had changed their operating procedures and moved on for weeks before we were able to get a build with this option enabled.
Thoughts, please? - Julian
