> So the failure mode is that rep-cache.db entries are not able to be > added while rep-cache.db is being verified. I am not convinced that > this is a problem.
I think that this case leads to multiple problems: 1) Commits happening at the same time as verify will hang for the duration of sqlite busy timeout. 2) These commits will complete with a post-commit error. 3) No entries will be added to rep-cache.db. Unless fixed, following commits may work without deduplication. Repository verification can be a regular procedure and can take a long time for large repositories. And in that case the mentioned problems can also happen regularly. > The obvious workaround, in case someone runs into that, is for the > admin to run build-repcache afterwards. (Incidentally, we might want > have the "post-commit FS processing failed" error message namedrop > «svnadmin build-repcache» when the underlying error code indicates an > SQLite error.) I assume that the patch fixes the problem in such a way that it does not require any additional workarounds and does not worsen any other characteristics. At the same time, I would like to note that the workaround does not fix all problems. It fixes only 3) and only if it is called at the right time. > Yes, build-repcache will error out in this situation. Why is that a problem? I think this is a problem for similar reasons. It may be unexpected that the read-only verify operation can lead to an error when another maintenance operation such as 'svnadmin build-repcache' is called. To completely avoid failures, it may be necessary to separate operations by time, and this is not always possible. > What effect does the patch have on _correctness_ of verification? What > kinds of corruptions can be detected by the incumbent code but not with > your patch? > > Isn't there an alternative approach that does not affect the correctness > of verification as much as this approach? The patch does not change the verification process, only the process of fetching entries. In the previous approach entries were fetched during one large query and now they are fetched in small batches. In this way: 1) If rep-cache.db is not changed during its verification, the new approach should be equivalent to the previous one. 2) If new entries are added to the rep-cache.db during its verification, the new approach has a guarantee that all entries that existed at the time of the call of 'svnadmin verify' will be verified. So I think that it should not affect the correctness of verification. Regards, Denis Kovalchuk
