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

Possible bug in 1.7: svn cleanup can't recover after a failed update (with 1.6 it was possible)

From: Sebastian Esponda <sesponda_at_gmail.com>
Date: Tue, 10 Jan 2012 10:32:18 -0300

(Note: I'm "almost" sure this is something to be fixed for 1.7, being
the reason why I'm also addressing this to the Dev list... feel free
to correct me if I'm wrong.. Thanks)

Hello there,

We are facing the following issue with svn 1.7:

Exec summary:
- We need to incrementally checkout a multi-GB repository, which
contains unexpected files with invalid chars from time to time.
- We need to checkout as much as possible for analysis. We don't have
commit rights to fix the filenames.
- With svn 1.6, every time we faced that issue in our way, we could
clean up the aborted update command, and continue checking out the
other directories (just skipping the failed one).
- With svn 1.7, the last failed update leaves the _entire_ multiGB
local working copy in an unrecoverable state, being impossible to fix
it with svn cleanup, forcing us to check several hundred MBs again and
manually moving uncommitted changes.

Details:

1) Clean install of svn 1.7 on Windows 7 32 bits.
2) Clean checkout of multi-GB repo, using --deph immediates to avoid
checking out everything.
3) Checked out more dirs later.

4) Issue: one dir contains a file with a pipe (|) char in its name.

4.a) This is what happened with svn 1.6:
4.a.1) check out failed.
4.a.2) deleted the directory, run svn cleanup OK.
4.a.3) retry with "--set-depth empty" to avoid checking out that file.
4.a.4) Continue with the other directories.

4.b) This is what happens with svn 1.7.2 (r1207936)

4.b.1) check out fails (I've replaced some chars in the path below to
comply with confidentiality requirements).

svn: E720123: Can't move 'C:\work\aa\.svn\tmp\svn-60C55E31' to
'C:\work\aa\bb\cc\dd\ee | ff.pdf': The filename, directory name, or
volume label syntax is incorrect.

4.b.2) Attempt svn cleanup. Output:

svn: E155004: Working copy 'C:\work\aa\bb' locked.
svn: E155004: 'C:\work\aa' is already locked.
svn: E155037: Previous operation has not finished; run 'cleanup' if it
was interrupted
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

4.b.3) Retry from parent dir:

c:\work\aa>svn cleanup
svn: E720123: Can't move 'C:\work\aa\.svn\tmp\svn-3C8DD0F0' to
'C:\work\aa\bb\cc\dd\ee | ff.pdf': The filename, directory name, or
volume label syntax is incorrect.

4.b.4) Each retry generates a new "svn-{4 bytes in hex}" file in
.svn\tmp, failing again.
4.b.5) From this point on, the situation is unrecoverable (meaning: if
it is, we don't know how...).

Insight: with 1.6, we just deleted the .svn db related to the
offending dir. With 1.7, there is one monolithic .svn db dir, and we
don't know how to say to svn clean up "just abort the last command, do
not try to finish the transaction".

Should this be reported as a bug? Is there any way to fix the local
copy, avoiding repeating a complete checkout?
Any ideas or suggestions from you will be very appreciated...
Thanks!

PD: there is a similar issue posted in the old issue tracker (id
4024), but that one has been closed because the reproduction steps
were directly messing with the db. This is not the case.. in this
scenario, a failed update is retried by the cleanup command, being
impossible to recover from that.
Received on 2012-01-10 16:04:16 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.