You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2011/04/14 09:19:03 UTC
RE: svn up problem using latest trunk revision (1092011)
> -----Original Message-----
> From: Marc Haesen [mailto:Marc.Haesen@oneaccess-net.com]
> Sent: donderdag 14 april 2011 8:11
> To: dev@subversion.apache.org
> Subject: svn up problem using latest trunk revision (1092011)
>
> I am using the latest version of svn on trunk compiled for windows. When
> executing the following commands:
>
>
>
> svn co http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi
> .
>
> svn up -r5516 .
>
>
>
> I get the following error:
>
>
>
> Updating '.' ...
>
> svn: E155017: Checksum mismatch while updating
> 'D:\temp\temp\HplAtm128SpiP.nc':
>
> expected: 95f9d9ccfd75a2e9764c2f2d4904152a
>
> actual: 57bf0651502cd65d9446e2f44f661526
This patch would only affect the error:
if (recorded_base_checksum && expected_base_checksum
&& strcmp(expected_base_checksum, recorded_base_checksum) != 0)
return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
_("Checksum mismatch for '%s':\n"
" expected: %s\n"
" recorded: %s\n"),
svn_dirent_local_style(fb->local_abspath, pool),
expected_base_checksum, recorded_base_checksum);
While you got the error from a different function.
Are you sure you tested this on a clean checkout?
(What HEAD version did you get on the checkout? I can't reproduce it here)
Bert
RE: svn up problem using latest trunk revision (1092011)
Posted by Marc Haesen <Ma...@oneaccess-net.com>.
Indeed, r1092033 fixes the problem to.
Thanks,
Marc
-----Original Message-----
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: donderdag 14 april 2011 9:49
To: Marc Haesen; dev@subversion.apache.org
Subject: RE: svn up problem using latest trunk revision (1092011)
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: donderdag 14 april 2011 9:19
> To: 'Marc Haesen'; dev@subversion.apache.org
> Subject: RE: svn up problem using latest trunk revision (1092011)
> This patch would only affect the error:
>
> if (recorded_base_checksum && expected_base_checksum
> && strcmp(expected_base_checksum, recorded_base_checksum) !=
0)
> return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
> _("Checksum mismatch for '%s':\n"
> " expected: %s\n"
> " recorded: %s\n"),
> svn_dirent_local_style(fb->local_abspath, pool),
> expected_base_checksum, recorded_base_checksum);
>
> While you got the error from a different function.
>
> Are you sure you tested this on a clean checkout?
>
> (What HEAD version did you get on the checkout? I can't reproduce it
here)
While I couldn't reproduce this issue, I expect that it is fixed by
r1092033.
(In a different way than in your patch: It uses SHA1 properly when the
server doesn't provide a checksum)
Bert
RE: svn up problem using latest trunk revision (1092011)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: donderdag 14 april 2011 9:19
> To: 'Marc Haesen'; dev@subversion.apache.org
> Subject: RE: svn up problem using latest trunk revision (1092011)
> This patch would only affect the error:
>
> if (recorded_base_checksum && expected_base_checksum
> && strcmp(expected_base_checksum, recorded_base_checksum) != 0)
> return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
> _("Checksum mismatch for '%s':\n"
> " expected: %s\n"
> " recorded: %s\n"),
> svn_dirent_local_style(fb->local_abspath, pool),
> expected_base_checksum, recorded_base_checksum);
>
> While you got the error from a different function.
>
> Are you sure you tested this on a clean checkout?
>
> (What HEAD version did you get on the checkout? I can't reproduce it here)
While I couldn't reproduce this issue, I expect that it is fixed by
r1092033.
(In a different way than in your patch: It uses SHA1 properly when the
server doesn't provide a checksum)
Bert
RE: svn up problem using latest trunk revision (1092011)
Posted by Marc Haesen <Ma...@oneaccess-net.com>.
Yes, I started from an empty directory. On the initial checkout I get
revision 5538
I have the same problem on a linux version (1091675) compiled on debian.
Here is the complete output:
mahae@linux-nagios:~/temp$ svn co
http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi .
A Atm128Spi.nc
A Atm128SpiP.nc
A sim
A sim/Atm128SpiC.nc
A Atm128SpiC.nc
A HplAtm128SpiP.nc
A Atm128Spi.h
A HplAtm128SpiC.nc
Checked out revision 5538.
mahae@linux-nagios:~/temp$ svn up -r5516 .
Updating '.' ...
svn: E155017: Checksum mismatch while updating
'/home/mahae/temp/HplAtm128SpiP.nc':
expected: 95f9d9ccfd75a2e9764c2f2d4904152a
actual: 57bf0651502cd65d9446e2f44f661526
With the patch applied, everything seems to work fine and the svn up
-r5516 is giving the expected result.
Regards,
Marc
-----Original Message-----
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: donderdag 14 april 2011 9:19
To: Marc Haesen; dev@subversion.apache.org
Subject: RE: svn up problem using latest trunk revision (1092011)
> -----Original Message-----
> From: Marc Haesen [mailto:Marc.Haesen@oneaccess-net.com]
> Sent: donderdag 14 april 2011 8:11
> To: dev@subversion.apache.org
> Subject: svn up problem using latest trunk revision (1092011)
>
> I am using the latest version of svn on trunk compiled for windows.
When
> executing the following commands:
>
>
>
> svn co
http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi
> .
>
> svn up -r5516 .
>
>
>
> I get the following error:
>
>
>
> Updating '.' ...
>
> svn: E155017: Checksum mismatch while updating
> 'D:\temp\temp\HplAtm128SpiP.nc':
>
> expected: 95f9d9ccfd75a2e9764c2f2d4904152a
>
> actual: 57bf0651502cd65d9446e2f44f661526
This patch would only affect the error:
if (recorded_base_checksum && expected_base_checksum
&& strcmp(expected_base_checksum, recorded_base_checksum) != 0)
return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
_("Checksum mismatch for '%s':\n"
" expected: %s\n"
" recorded: %s\n"),
svn_dirent_local_style(fb->local_abspath, pool),
expected_base_checksum, recorded_base_checksum);
While you got the error from a different function.
Are you sure you tested this on a clean checkout?
(What HEAD version did you get on the checkout? I can't reproduce it
here)
Bert