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. > $ svnadmin create repo > $ svn import -mm repo/format file://`pwd`/repo/A/f > $ svn co file://`pwd`/repo wc > $ svn wc/A wc/B > $ svn mv wc/B/f wc/B/g > > $ svn st wc > D wc/A > > moved to wc/B > D wc/A/f > A + wc/B > > moved from wc/A > D + wc/B/f > > moved to wc/B/g > A + wc/B/g > > moved from wc/B/f > > $ sqlite3 wc/.svn/wc.db "update nodes set moved_to = null" > $ svn st wc > D wc/A > D wc/A/f > A + wc/B > D + wc/B/f > A + wc/B/g -Marc
