subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <hartman.nat...@gmail.com>
Subject Re: svn: E160013: File not found: transaction '41-1j'
Date Thu, 15 Jul 2021 20:52:18 GMT
On Thu, Jul 15, 2021 at 12:18 PM David Aldrich
<david.aldrich.ntml@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.)

Mime
View raw message