Toby Thain wrote:
>
> On 8-Mar-05, at 4:01 PM, Alexander Kitaev wrote:
>
>> Hello Toby,
>>
>>> Thanks for the response. I've already had to fix this
>>> particular repo (reverse merge), and I can't give you access
>>> to it, but I can make a test repo somewhere that I can give
>>> you access, and see if I can reproduce it.
>> Actually I do not need repository access to reproduce the problem. What I
>> would like to have are the files that got corrupted - base version and wc
>> version of the file as they were before commit that resulted in corrupted
>> version in repository. I will make the same commit on my computer
>> (into my
>> local repository) and as I think the problem is on the client side, I
>> will
>> be able to get corrupted file in my repository as well.
>
> Alexander
>
> We have just seen another example of a corrupt commit: File was changed
> at r34 and r30, both those revisions are corrupt, and I cannot therefore
> give you the wc version committed at r30 since the corruption was
> detected too late.
>
> However this does show that the bug is alive and well. In this case the
> project was Java, and the commit was made from a Windows box. In the
> previous instance it was a C++ project and committed from OS X. So I'm
> still waiting to catch the bug red-handed. :-(
I ran into a similar problem.
What I saw in the file after the commit was that parts of it were
missing. The working copy was still OK but the update on another box wasn't.
I suspect one of the following reasons:
- JavaSVN doesn't handle tight memory situations very well
- The diffs are calculated wrong.
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
Received on Wed Mar 23 19:40:03 2005