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
Received on 2017-03-13 12:27:36 CET