On Thu, Jul 15, 2021 at 12:18 PM David Aldrich <david.aldrich.n...@gmail.com> wrote: > > Hi Nathan > > Thanks for your answer. I didn't make this clear, but I do understand the > concept of Update and had updated the working copy before attempting the > rename. > > I have, just now, made a clean checkout and repeated the rename, but I get a > similar result. > > Another team member had attempted the rename earlier today but it failed with > a permissions error. > > Could there be some incomplete transaction lurking in the database that is > causing a tree conflict? > > Or some other problem, possibly associated with the use of spaces? > > Best regards > David
Hello David, The E155011 "Directory ... is out of date" error is Subversion trying to be helpful by wrapping what could be an obscure commit error with a more friendly one; however in this case it wasn't helpful. The E160013 "File not found: transaction..." error is the important one in this case. I doubt that spaces in the path are causing the issue; my $employer's repo contains filenames and directories with spaces and we have renamed things many times without issues; however I won't completely discount that possibility. There might be some edge case. Let's try to narrow down the cause: Do you know which version of Subversion is running on the server? Is it a *nix or Windows based server? What type of server is it -- if unsure you can tell by the URL you're using to access it: local (file://), svnserve (svn://), or httpd-based (http:// or https://). Is the item in question pulled in via svn:externals? Is it a symlink? Can you see the file listed if you run 'svn ls' using the server-side URL, e.g., if your server is svnserve, something like: $ svn ls "svn://<repo_URL>/<snip>/Feasibility Studies/Use Case Analysis/TML/RIC_Initial_Use_Case_Analysis" (Remember to enclose the path in quotes.) If that's not found, gradually remove one item at a time from the end of the path: $ svn ls "svn://<repo_URL>/<snip>/Feasibility Studies/Use Case Analysis/TML/" You can also run 'svn info' with the same URLs, with spaces, and then you should see the URL encoded with %20 in place of spaces. Also, you might try using %20 in place of spaces and see if that makes a difference. Perhaps by mistake one of those spaces is a different codepoint, so looks like a regular space, but isn't. Have you (or colleagues) attempted other commit operations in the meantime and have they succeeded or failed? If it's a httpd-based server, do httpd's logs show anything that seems significant? Dumb question: Could the server be low on disk space? As a possible workaround: You could perhaps try the rename as a server-side operation? i.e., 'svn mv' giving the old and new server-side URL and a commit message. Let us know... Nathan P.S., You asked if any stale transactions might be lurking. You can check with the 'svnadmin' subcommand 'lstxns'. That would need to be run on the server. It is described here: https://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deadtxns (Search for "lxtxns" on that page; I suggest not to rush to delete any you might find, in case they offer some helpful clues.)