On Fri, Oct 26, 2012 at 07:07:45PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Fri, Oct 26, 2012 at 12:45:49 +0200:
> > I'd like to have this feature because it will make my work a little
> > easier should I ever be tasked again with repairing broken repositories.
> > When I last had to repair a couple of dozen revisions in a broken
> > repository I was rather annoyed at the way 'svnadmin verify' currently
> > works. The current behaviour of 'svnadmin verify' is not very useful for
> > answering the question "which revisions are broken?". It only answers
> > the question "which is the first broken revision?", which so far has
> > never been sufficient information when I had to verify a repository.
> >
>
> OK, what information would you want?
I want to know which revisions are broken in the sense that they
won't check out, cannot be updated to, or won't diff, etc. because
of broken representations or other forms of corruption.
I don't need details about the actual nature of corruption that
has occurred in this summary report because that is something
I can figure out in a separate step.
> > Usually I need to quickly assess the overall impact of repository damage,
> > and also quickly assess the overall impact of fixes I make to repair the
> > repository. The number of the first broken revision isn't enough information.
> >
>
> Right. But Julian already pointed out that the implementation of this
> patch will report a single corruption multiple times, and I hinted at
> one of my mails that the way to avoid this problem is to push the logic
> into a DAG-aware tree walk.
I don't think this is a problem at all. If revision A has a broken
rep and revision B refers to that rep, then both A and B are broken.
Even if the source of the corruption is in A only I want to know that
B is affected by it. Because B is essentially just as broken as A from
the user's point of view (somebody who wants to use the repository and
who doesn't understand FSFS internals).
I don't really care about detailed info such as which revision is
actually causing the problem. That would be nice but isn't required.
> Have you actually tried this patch yet?
Nope.
> Can you get the information you need from svnadmin-with-this-patch
> despite the shortcoming Julian has pointed out?
Yes!
> > A proper 'svnadmin verify' loop will also collect errors reported and
> > show a summary at the end. That's additional overhead if coding this as
> > a loop on the command line. The repos library can easily collect this
> > information internally and pass it as the final notification.
>
> I am not sure that I understand this argument.
Output of a quickly written loop on the command line is usually not
going to be as nice and comprehensive as that of a well implemented
core feature. Makes sense?
> Sounds like you're evaluating Prabhu's patch against a list of features
> you'd like 'svnadmin verify' to grow someday. I think it would be
> helpful if you shared that list --- it would let people share their
> thoughts on the whole context/plan, not just on this patch.
The only item on that list would be the summary report already mentioned.
I just want to know how bad the overall impact of corruption is,
i.e. which revisions are affected by one or more instances of
actual corruption that have occurred in the repository.
Received on 2012-10-27 10:47:45 CEST