[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 4098] New - Possible bug in 1.7: svn cleanup can't recover after a failed update (with 1.6 it
From:       sesponda () tigris ! org
Date:       2012-01-15 17:04:22
Message-ID: iz4098 () subversion ! tigris ! org
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=4098
                 Issue #|4098
                 Summary|Possible bug in 1.7: svn cleanup can't recover after a
                        | failed update (with 1.6 it was possible)
               Component|subversion
                 Version|1.7.x
                Platform|All
                     URL|
              OS/Version|Windows 7
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|unknown
             Assigned to|issues@subversion
             Reported by|sesponda






------- Additional comments from sesponda@tigris.org Sun Jan 15 09:04:21 -0800 2012 -------
Hello there,

I'm posting this issue after some emails in the userlist.

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".


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.

PD2: snv -r0 didn't work: (svn: E155037:
Previous operation has not finished; run 'cleanup' if it was
interrupted)
This is the reason why I believe the local repo is in a
non-recoverable state, because any command request a clean up, but a
clean up fails.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2908955

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]