On Fri, Feb 23, 2018 at 01:06:36PM -0800, Myria wrote:
> I'm not subscribed to this mailing list, so I have no standard way to
> reply to Philip's email. I don't even know his email address.
>
> > That pattern, all of MD5, SHA1 and size matching, is exactly what
> > happens if a SHA1 collision is committed using an old version of
> > Subversion where the rep-cache does not detect collisions. The first
> > part of the collision would have been committed in r604440 and the
> > second part in r605556.
> >
> > If that is the case, and a SHA1 collision did occur, then:
> >
> > svnadmin verify -r604440 path/to/repository
> >
> > will succeed while:
> >
> > svnadmin verify -r605556 path/to/repository
> >
> > will fail with an MD5 checksum error.
> >
> > If this is what you see then unfortunately the colliding r605556 content
> > has been elided and the r605556 revision is corrupt.
>
> The revision 605556 is simply the current revision number of the
> repository at the time of the attempted commit, and is unrelated to
> the problem. If I attempt the commit now, it's a higher number, but
> otherwise the same error message.
>
> Something I did notice is that the commit I'm trying to do is a
> reversion to an older version of the same file. The revision of the
> file throwing the error at 604440 is identical to the file I'm trying
> to commit, but the file currently in the repository is different.
>
> If I commit a dummy version of the file, then commit the version I
> actually want, the latter commit works. Could the collision be in a
> "diff" instead of the files themselves?
>
> Melissa
Hi Melissa,
What is the output of the 'svnadmin verify' commands which Philip
wrote about above?
I think the cause of the problem is still unclear, and we probably
won't find a good answer without more information such as this.
Stefan
Received on 2018-02-23 22:25:41 CET