checksums, another data point

Hi.

After 2 weeks of not having not much time, I tried to update my
working copy of the svn tree, and got the dreaded checksum error.

The interesting part is that I got exactly the same as Garrett
reported earlier here:

  http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=30230

I read the whole checksums threads in the archive again to be sure
that I did not miss something the first time, but it seems that the
thread above simply died away?

Anyhow, as I said, I have exactly the same problem (win-tests.py),
same checksums (expected: f9c9027cfe19f92f7f6e1b9d3d316acf, actual:
9f30bad101c64a873b0f2c05d529924c) and so on.

I last updated my tree on the 18th to r4420. Unfortunately, I cannot
say for sure anymore, from which version I updated. I recompiled
subversion that day, so I am currently using r4420, when I run into
that problem. For updating to r4420 I used a binary from r4250.

As the mentioned thread says, both my files, the base and the working
copy are with UNIX line ending, matching the "actual" checksum and
when I replace \n by \r\n I get the expected checksum.

As shown in the post from David, both checksums can actually be found
in the repository:

$ svn cat http://svn.collab.net/repos/svn/trunk/win-tests.py -r 4371 | openssl md5
9f30bad101c64a873b0f2c05d529924c
$ svn cat http://svn.collab.net/repos/svn/trunk/win-tests.py -r 4105 | openssl md5
f9c9027cfe19f92f7f6e1b9d3d316acf

The changlog shows (which apparently nobody mentioned until now):

$svn log -r 4371 .
------------------------------------------------------------------------
rev 4371: rassilon | 2003-01-13 23:43:13 +0100 (Mon, 13 Jan 2003) | 3 lines

* Just about everything else that wasn't test output, a binary file,
or already to set to CRLF: Set svn:eol-style to native.

------------------------------------------------------------------------

So it seems, that when I updated to r4420 (with the binary compiled
from r4250), svn failed to update the checksum correctly.

Oh! My! God!

After trying for more than half an hour to reproduce the behaviour
using the older binaries I have still lying around, I just noticed the
filename for the first time really: win-test.py. Sounds familiar?
Perhaps from

  http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=219941
  ("READ ME: working copy ickiness!" from Ben)

It seems that changing text-bases isn't a good idea when md5sums are
used in parallel. :-)

Although I have to admit, I still get a headache when I try to follow
when the text-base resp. working copy had which line ending and why, I
am pretty sure I have found the source of the problem in this case.

And the solution is: don't mess around with the text-base, even when
instructed to do so. ;-) Or, well, alternatively, maybe update the
checksum, too.

And does

  http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=30132
  ("win-tests.py broken in the repository?")

have influence on this (I think not, because the the sums should be
correct for whatever is stored, but maybe the eol-conversion gets in
between)? Or was it all about this last issue and I just embarrassed
myself? ;)

HTH,

        Benjamin.