On Mon, Feb 27, 2012 at 03:25:00PM -0800, Jason Wong wrote: > So I think I misunderstood why the error messages were occurring. > I had thought that there was a condition done by this check (in 1.7), > that was erroneously causing svn to reject the attempt to check-in.
The purpose of this error is to abort a commit in a situation where Subversion would otherwise create a commit that has the wrong idea about the number of predecessor revisions of the repository's root node. The root node is changed in every commit. So for revision N, the number of predecessor revisions should add up to N (including revision zero). Somehow, this count sometimes ends up being wrong during a commit, and such commits are now rejected. However, when checking the count for sanity, Subversion accounts for the fact that older revisions might have gotten the count wrong. I.e. the check only prevents the count from becoming even more wrong in future revisions than it already is. > I guess I am wondering that if this is the case, then why is it that > if the check-in fails, and then we manually check it in again using > tortoisesvn, that it works the second time? As far as I know, we don't know what the underlying problem is yet. So I'm afraid I cannot answer all of your questions in a satisfactory manner because I don't know the answers. Daniel might know more -- he has been following the problem more closely than me. And I hope he will correct me if I'm making any wrong or misleading statements in this post :) > So the errors prevent the bug from corrupting new revisions? Yes. This error is a sanity check. Right now, it's a sort of good thing to be getting the error. Just not as good as a proper fix for the, as of yet unknown, underlying problem that's triggering the sanity check. > Is this something between the 1.7 versions or would this have been in 1.6 > versions as well? We currently assume that is also happens with 1.6. > We have been using svn for a while now and I am > wondering what this means that for 1.6, that this issue has been > occurring from communcations between 1.6 client and 1.6 server. It has probably been happening since before the 1.7 release. The problem was first discovered in the ASF repository. The first occurrence there has been traced to a time before 1.7.0 was released. At the time the ASF server was still running 1.6, and the first commit that introduced the problem in the ASF repository was very likely a 1.6 client. > Also, is this bug something that svnadmin verify will not detect? > The last time we ran svnadmin verify, it said all was good. Apparently, svnadmin verify won't find it. This should probably be fixed. But the priority right now is to understand why it is happening in the first place. > If it is the case that this bug has been occuring for a long time, > what are the implications of the history links for affected > revisions? 'svn log' skips some revisions where it shouldn't. This is the only harmful effect of this bug, as far as I know. > When you say the history links are incorrect, does it > just put in a random value or is it actually unreadable values? I don't know if it is random or somehow predetermined. That depends on how the wrong predecessor value actually comes about. > Does this mean subsequent revisions that occur after these bad > revisions will propagate this bad information? Yes, the predecessor count of subsequent revisions is off by some constant value. > A developer asked me to pose the following question. If he was to > open a bad revision, would the client fail and give an error prompt > or would it display history information which could belong to other > files? So far this hasn't triggered any noticeable errors apart from missing items when viewing the log history of a path. Once the problem was discovered by inspection of 'svn log' output, a sanity check was put in place to prevent the problem from happening in new revisions. This check is what you are hitting. What we need to do now is to figure out why it's happening, and then fix that problem.
