Re: checksumming weird in 0.18

solo turn wrote:

>--- Philip Martin <philip@codematters.co.uk> wrote:
>
>
>>>it was "svn up", the operation "A base" was the result of a "move
>>>folder".
>>>
>>>
>> ...the result of a "move folder"
>>
>>
>somebody else moved the folder. i did an update.
>no contents modifications.
>no local modifications.
>client and server are 0.18.
>ra method: https.
>file size: 163 bytes.
>

Well, it looks like you didn't get enough beer on Saturday after all. :-)

What you wrote above is yet another prose description. Here's what a
real description would've looked like:

[tree structure]
A/B/G/mu
iota

[server]
svn 0.18 (released), apache 2.0.44 (released)
on i686-pc-linux-gnu (RedHat 7.3)
using ra_dav

[client 1 (svn 0.18 on Win2k)]
svn co http://server/project
A A
A A/B
A A/B/G
A A/B/G/mu
A iota
Checked out revision 1

[client 2 (svn 0.18 on Win2k)]
svn co http://server/project
A A
A A/B
A A/B/G
A A/B/G/mu
A iota
Checked out revision 1

[client 1 (svn 0.18 on Win2k)]
$ svn mv A/B A/X
$ svn commit -m 'move A/B to A/X'
Deleting A/B
Adding A/X
Adding A/X/G
Adding A/X/G/mu
Transmitting file data .
Committed revision 2

[client 2 (svn 0.18 on Win2k)]
$ svn update
D A/B
A A/X
A A/X/G
A A/X/G/iota
svn: A checksum mismatch occurred
svn: apply_window: checksum mismatch after applying text delta
(trunk/base/.svn/tmp/text-base/bla.properties.svn-base):
 expected checksum: lns="svn:">
<entry
   committed-rev="523"
   name="svn:this_dir"
   committed-date="2003-03-08T11:11:34.367573Z"
   url="https://myserver/svnrep/trunk/projects/my_project"
   last-author="author"
   kind="dir"
   revision="0"/>
</wc-entries>

   actual checksum: 0acddde1c4925f7f2c0059a4d9c8cf32

>>provide a recipe that allows that person to reproduce the problem.
>>
>>
>i think there is no (easy) way of reproducing an error like this one.
>i anyway did not succeed in doing it.
>
>but somebody should know, where the checksums are stored, and why
>something else can be in this storage area. i always thought a
>checksum is a rather fixed storage area, and i'm wondering why it is
>a pointer.
>
>
The checksum is not a pointer. But the memory where the checksum is
stored is allocated on the heap, and a pointer *points* to that. So
either the pointer could be frobbed, or the heap could be corrupted.
There's no such thing as a "fixed storage area"; we're not Pascal
programmers from the '80s.

But that's all beside the point. When writing a reproduction recipe for
a bug report, or just describing what you'd done, you should *not* try
to guess what the code does. Just write down what *you* did -- as
precisely as possible -- and then whoever goes to fix the bug will
figure out what the code is doing.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org