Re: svn: E160013: File not found: transaction '41-1j'

2021-07-16 Thread David Aldrich
Hi Daniel and Nathan

Thanks for your replies.

The client is svn 1.13.0
The server is 1.14.0
Protocol is http

Before the rename I see:

$ ls
  'Traffic Steering'   drafts

The svn mv yields:

$ svn mv Traffic%20Steering RIC_Initial_Use_Case_Analysis
svn: E155010: Path '/home//SVNProj/mnd-ric/Feasibility Studies/Use
Case Analysis/TML/Traffic%20Steering' does not exist

Is that helpful?

Best regards
David

On Fri, Jul 16, 2021 at 1:31 PM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Thu, Jul 15, 2021 at 16:52:18 -0400:
> > 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.
>
> Good idea, but there's no reason to try blindly; running «svn ls» on the
> containing directory and «svn info» on the file, both of which you have
> suggested above, is sufficient to rule this out.
>
> Speaking of which, going back to the original error message, there's
> something I didn't notice at first:
>
> > > > > svn: E160013: File not found: transaction '41-1j', path
> '/Feasibility%20Studies/Use%20Case%20Analysis/TML/RIC_Initial_Use_Case_Analysis'
>
> This is a libsvn_fs_fs error message, and the path is percent-escaped.
> However, libsvn_fs_fs shouldn't be seeing percent-escaped paths at all.
>
> What's the version number on the client and server?
>
> > If it's a httpd-based server, do httpd's logs show anything that seems
> > significant?
>
> As mentioned upthread, svnserve has logs too, and successful commits
> would also show up in «svn log ^/».
>
> > Dumb question: Could the server be low on disk space?
>
> I don't see how that could cause an E160013?
>
> Cheers,
>
> Daniel
>


Re: svn: E160013: File not found: transaction '41-1j'

2021-07-16 Thread Daniel Shahaf
Nathan Hartman wrote on Thu, Jul 15, 2021 at 16:52:18 -0400:
> 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.

Good idea, but there's no reason to try blindly; running «svn ls» on the
containing directory and «svn info» on the file, both of which you have
suggested above, is sufficient to rule this out.

Speaking of which, going back to the original error message, there's
something I didn't notice at first:

> > > > svn: E160013: File not found: transaction '41-1j', path 
> > > > '/Feasibility%20Studies/Use%20Case%20Analysis/TML/RIC_Initial_Use_Case_Analysis'

This is a libsvn_fs_fs error message, and the path is percent-escaped.
However, libsvn_fs_fs shouldn't be seeing percent-escaped paths at all.

What's the version number on the client and server?

> If it's a httpd-based server, do httpd's logs show anything that seems
> significant?

As mentioned upthread, svnserve has logs too, and successful commits
would also show up in «svn log ^/».

> Dumb question: Could the server be low on disk space?

I don't see how that could cause an E160013?

Cheers,

Daniel


Re: svn: E160013: File not found: transaction '41-1j'

2021-07-16 Thread Daniel Shahaf
David Aldrich wrote on Thu, Jul 15, 2021 at 17:18:47 +0100:
> Another team member had attempted the rename earlier today but it failed
> with a permissions error.

That's probably unrelated, but still, please quote the error message.

> Could there be some incomplete transaction lurking in the database that is
> causing a tree conflict?

No.  What you're seeing isn't a tree conflict.  Conflicts are
a client-side concept and are triggered by update/switch/merge operations.
Besides, if an incomplete transaction _could_ somehow cause a conflict,
then it could also be updated to, and we'd have noticed that.

(Background reading pointers for interested devs: svn_fs_root_t;
NODES.op_depth.)

Cheers,

Daniel


Re: svn: E160013: File not found: transaction '41-1j'

2021-07-16 Thread Daniel Shahaf
David Aldrich wrote on Thu, Jul 15, 2021 at 15:54:00 +0100:
> I'm trying to rename a directory and I get this error on commit:
> 
> Adding TML/RIC_Initial_Use_Case_Analysis
> svn: E155011: Commit failed (details follow):
> svn: E155011: Directory '//Feasibility Studies/Use Case
> Analysis/TML/RIC_Initial_Use_Case_Analysis' is out of date
> svn: E160013: File not found: transaction '41-1j', path
> '/Feasibility%20Studies/Use%20Case%20Analysis/TML/RIC_Initial_Use_Case_Analysis'

Hang on.  "Feasibility Studies" is a child of the root in the E160013
error message, but child of something other than the root in the second
E155011 line.  Is that indeed so, or did you redact the two messages
differently?

> I guess the problem is associated with the fact that the path contains
> spaces.
> 
> Any advice on how to resolve this please?

Review your start-commit and pre-commit hooks.

Review your server's logs for any concurrent commit attempts.  (This
applies to everything except file://, not only to http/https.  If you
use file://, you can implement logging in pre-commit, or look at
revisions that have in fact been committed right around the time of the
failed commit attempt.)

Cheers,

Daniel


Re: svn log xml hangs and produces too many logentry closing tags

2021-07-16 Thread Daniel Shahaf
Attila wrote on Tue, Jul 13, 2021 at 23:48:48 +0200:
> Hi
> 
> I have a problem getting the svn log in a branch after sync-merging a commit 
> from trunk.
> This commit in trunk is a merge of an old and complex branch with many 
> commits.
> 
> The client accessing the repository over svn:// url.
> (paths and text is redacted)
> The  head revision is: 10801
> 
> When I run the following command on the client (in the working copy), it 
> prints a long partial xml-log output, then hangs.
> /usr/bin/svn log --xml -g -v -r 10701:HEAD /path/to/branch-wc
> 
> When observing in "top", the command uses no visible CPU resources on hang. 
> (I waited ca. 2 minutes)
> The hanging command does mot exits on CTRL-c, it does not exits on "kill 
> -TERM pid", I have to send "kill -KILL pid" to terminate it.
> 
> When I run the command with strace it hangs at read(4,
> ...SNIP...
> read(4, " ( ) ( 4:file true false ) ) ( 1"..., 16384) = 16384
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d83000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d81000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7f000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7d000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d7b000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d79000
> read(4, "***/-***_redacted_*_"..., 16384) = 14773
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d77000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d75000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d73000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d71000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d6f000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f63f1d6d000
> read(4,
> 
> When I observe the server, there is a CPU activity at the begin, but when the 
> client hangs, the server seems to be in idle.
> Just a corresponding svnserve process is there with no visible cpu usage.
> In svnserve.log is nothing relevant to see.
> 
> The svnserve command is:
> svnserve -d -r /path/to/repositories \
> --log-file=/var/log/svnserve.log \
> --memory-cache-size 1024 \
> --cache-txdeltas yes \
> --cache-fulltexts yes
> 
> When I try to get the xml-log on the server with the corresponding file:// 
> repository URL:
> /usr/bin/svn log --xml -g -v -r 10701:HEAD 
> file://path/to/local/repositories/project/branch
> The command finishes in ca 5-10 seconds and I get the xml output, but the 
> output has a way too many  lines.
> 
> There are 1217 occurrences of the string “ the string "" in the output xml.
> There are several thousand lines of  in a row in many places in 
> repeated blocks.
> 
> Details:
> Client and Server OS:
> Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 
> GNU/Linux
> 
> The repository is ca. 4 GB.
> Running "svnadmin verify" on the server founds no errors.
> I have no other problems with the server, checkout and commit works normal.
> 
> svn --version
> svn, version 1.10.4 (r1850624)
>compiled Feb 10 2021, 20:15:45 on x86_64-pc-linux-gnu
>  
> Copyright (C) 2019 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>  
> The following repository access (RA) modules are available:
>  
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>   - using serf 1.3.9 (compiled with 1.3.9)
>   - handles 'http' scheme
>   - handles 'https' scheme
>  
> The following authentication credential caches are available:
>  
> * Plaintext cache in /home/username/.subversion
> * Gnome Keyring
> * GPG-Agent
> * KWallet (KDE)
> 
> 
> Googling around gives me these two somewhat related hits:
> https://issues.apache.org/jira/browse/SVN-4856
> https://issues.apache.org/jira/browse/SVN-4711
> 
> But I do'nt use the --search parameter.
> 
> Is this a bug or are there any suggestions how to solve this problem?

It could be SVN-4856, which doesn't use --search either, or it could be
something else that happens whenever the output is large enough.  Could
you try «svn log -v -r HEAD:0 '^/' >/dev/null» without -g?  That might
not actually be large enough (considering HEAD is ≈11k and your output
had ≈33k cases of ), so you might have to create a