On Mon, Feb 27, 2012 at 8:09 AM, Stefan Sperling <s...@elego.de> wrote: > On Mon, Feb 27, 2012 at 07:36:39AM -0800, Jason Wong wrote: >> This is true. We have seen the bug happen before. The first occurence >> of this that we had seen was Dec. 7th, 2011, a few days after we went >> from 1.6.16 to 1.7.1. That was the first time we had seen that happen. >> At the time, we did not know about the cause and the developer who >> had encountered the error didn't report it and was able to work >> around it. From the Apache logs we have: >> >> [Wed Dec 07 15:16:36 2011] [error] [client 10.2.3.1] predecessor >> count for the root node-revision is wrong: found 59444, >> committing r59478 [409, #160004] > > Just to be clear: These errors emitted by the 1.7.1 server prevent the > bug from corrupting new revisions. With a 1.6 server the problem would > go unnoticed and create bad revision data. > > When this corruption occurs, the repository still works. > But the history links for affected revisions are incorrect.
Hi Stephan. 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. 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? So the errors prevent the bug from corrupting new revisions? Is this something between the 1.7 versions or would this have been in 1.6 versions as well? 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. Also, is this bug something that svnadmin verify will not detect? The last time we ran svnadmin verify, it said all was good. 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? When you say the history links are incorrect, does it just put in a random value or is it actually unreadable values? Does this mean subsequent revisions that occur after these bad revisions will propagate this bad information? 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? Thanks. Jason.
