Re: wc.db: corruption after move?

On 26.11.2013 18:27, Branko Čibej wrote:
> On 26.11.2013 18:08, Philip Martin wrote:
>> Marc Strapetz <marc.strapetz_at_syntevo.com> writes:
>>
>>> We are encountering working copies with
>>>
>>> nodes.presence = moved and nodes.moved_to = <null>
>> What does "nodes.presence = moved" mean? There has never been a moved
>> presence.

Sorry, actually in the underlying wc.db, it should be:

presence = normal and op_depth > 0 and moved_here > 0

>> Do you mean rows with nodes.moved_here=1 no corresponding rows with
>> non-null nodes.moved_to?

Exactly, that seems to be the case.

>> Or something else?
>>> 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?

> Marc is looking at some code that converts wc.db info to some internal
> structure ...
>
> Marc, can you please explain how the wc.db itself looks like? Hint: we
> don't support SmartSVN or SVNKit here. :)

Unfortunately I haven't seen such a wc.db until now, but when tracing
back the conversions we do, the resulting problematic wc.db *should*
look like as described above.

--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com