Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4098

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



    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.7.x
    • Fix Version/s: 1.10-consider
    • Component/s: libsvn_wc
    • Labels:
    • Environment:

      Windows 7


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

      Original issue reported by sesponda


          Issue Links



              • Assignee:
                subversion-importer Subversion Importer
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: