Mark Phippard wrote:
>> some temporary files created next to the corrupted file. So, I guess it
>> could be somehow related to the blocked files (e.g. when compiler is
>> running or file is under edit/merge) when adapter can't change either
>> resource or .svn metadata and leave corrupted state.
>>
> We would need a reliable reproduction recipe. We can then confirm if it
> also happens with JavaHL. The bottom line is that it is up to the
> Subversion API used not to corrupt itself.
>
I understand that. However it is appearing quite randomly. And the
only similarities I've spotted so far is JavaSVN and updating merging
locally changed files.
>> If anything like that happens there should be an easy way for the user
>> to restore working copy, e.g. get last resource from the repository.
>>
> I agree, but Subversion would have to provide an API we can call to do
> this. I assume you tried the cleanup action? I do recall from the
> Subversion users@ list that once you got this error you did not have much
> chance to repair it.
>
Right. Cleanup does not help. I wonder if you can simulate it somehow,
e.g. make it look like new file is coming from svn or maybe special kind
of API on JavaSVN?
regards,
Eugene
Received on Mon Nov 21 03:56:46 2005