[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc.db: corruption after move?

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 26 Nov 2013 20:38:08 +0000

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. If moved_to is missing Subversion usually
falls back to copy and delete:

$ 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

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-11-26 21:38:41 CET

This is an archived mail posted to the Subversion Users mailing list.