On Tue, Jan 10, 2012 at 2:32 PM, Sebastian Esponda <sesponda_at_gmail.com> wrote:
> (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)
Please don't crosspost to both lists, try to pick the correct
audience. In this case, I think users@ is best, mainly because other
users may be running into the same problem, may have suggestions /
workarounds, .... Also, quite some developers follow the users-list on
a regular basis, and if the discussion starts digressing into
implementation suggestions or deep internal details it can always be
redirected to dev@.
So, please drop dev@ in future replies to this thread.
More below ...
> 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!
Can you try if the following helps?
$ svn update -r0 offendingdir
Do the '--set-depth empty' trick (or '--set-depth exclude' ?)
Just guessing, but you may as well try it and see what happens :-).
> 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.
Even if the above "workaround" does the trick, I still agree with you
that this is a legitimate issue (it would still be very hard to
recover). I think you should file this in the issue tracker (the "old
issue tracker" at tigris.org is still the current one). And if the
workaround is effective, add it to the description please.
--
Johan
Received on 2012-01-11 01:01:02 CET