On 27.11.2013 11:32, Bert Huijben wrote: > > >> -----Original Message----- >> From: Marc Strapetz [mailto:marc.strap...@syntevo.com] >> Sent: woensdag 27 november 2013 09:30 >> To: Philip Martin >> Cc: Branko Čibej; users@subversion.apache.org >> Subject: Re: wc.db: corruption after move? >> >> On 26.11.2013 21:38, Philip Martin wrote: >>> Marc Strapetz <marc.strap...@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
