On 27.11.2013 11:32, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>> Sent: woensdag 27 november 2013 09:30
>> To: Philip Martin
>> Cc: Branko Čibej; users_at_subversion.apache.org
>> Subject: Re: wc.db: corruption after move?
>>
>> On 26.11.2013 21:38, Philip Martin wrote:
>>> Marc Strapetz <marc.strapetz_at_syntevo.com> writes:
>>>
>>>>>>> As far as I have been told, this has already been fixed and backported
>>>>>>> to 1.8.5. Still, for those users which already have this corruption, is
>>>>>>> there a way to recover their working copies with standard Subversion
>>>>>>> functionality? Could a Revert work? And if it currently does not, could
>>>>>>> the Revert be more tolerant, so it could handle such cases?
>>>>>> What operation is failing? Are you getting some error?
>>>>
>>>> I can't tell whether an operation fails, because an assertion when
>>>> reading the wc.db is hit before. I'd expect some operations (in the GUI)
>>>> to fail later, because we are assuming at various places that a moved
>>>> file must have a move-source. Is this assumption correct?
>>>
>>> Is that Subversion that is asserting? It would help if you showed the
>>> exact error or assertion.
>>
>> It's an assertion in SmartSVN which directly reads wc.db.
>>
>>> If moved_to is missing Subversion usually falls back to copy and delete:
>>
>> OK, so it's a valid wc.db state? I think that answers my question and I
>> will fix/remove SmartSVN's assertion accordingly.
>
> No, this is not a valid state. But we prefer to fix the problem how you got there, over updating Subversion to cope with invalid states everywhere.
Unfortunately the user who has encountered this problem doesn't know
(anymore) how he came into that state.
-Marc
Received on 2013-11-27 17:09:13 CET