SCM-Manager 3.11: svn: E160013: File not found during Web UI browsing

SCM-Manager (General)
1

Hello, I am an engineer setting up a production environment after migrating SVN repositories from SCM-Manager 1.6 to 3.11. I am posting this question because a “file not found” exception occurs intermittently and repeatedly when viewing the source tree or past commit history in the web UI for a specific repository.

error

"sonia.scm.repository.spi.SvnBrowseCommand.fetchExternalsProperty (line 179) sonia.scm.repository.spi.SvnBrowseCommand.createFileObject (line 163) … sonia.scm.repository.BrowserResultCollapser.collapseFolders (line 46) sonia.scm.repository.api.BrowserCommandBuilder.computeBrowserResult (line 173) org.tmatesoft.svn.core.SVNException: svn: E160013: File not found: revision , path ‘/<DIR_B>’ (or path ‘/<DIR_A>’) svn: E160013: Attempted to open non-existent child node ‘<DIR_B>’

Verified Facts (Investigation Steps)

To check for repository corruption, I directly inspected the actual filesystem on the local server using svnlook. "

- Actual Data Structure (svnlook tree -r 34): When querying the internal tree of the repository, only tags/ exists directly under the root (/). The bld directory in question is not located directly under the root, but properly exists under the hierarchy /tags/1.0.0/bld/… The original SVN data and files are completely intact without any loss or corruption.

- Direct Path Access Check: When accessing the full path /tags/1.0.0/bld directly via the web browser URL or SVN CLI, the page and file tree are displayed normally without any errors. This exception is triggered only when browsing starts from the repository root.

help me

2

Hi!

Thanks for reaching out to us! I’d love to reproduce your issue. We had a similar issue some time ago, but that should be fixed now.

Can you check whether your repository has externals in revision 34 …

svn propget svn:externals \
  --recursive \
  -r 34 \
  https://your-server/.../your-repository

… or at HEAD?

svn propget svn:externals \
  --recursive \
  https://your-server/.../your-repository

And if possible, could you check if this error disappears when you add another directory at root level (maybe in a clone of the repository in question)?

The best way would be if you could reproduce this error in another repository that you could give us as an export.

Thanks!
René

3

Thank you for your response.

Based on your suggestions, I performed some additional tests.

First, I checked the actual SVN structure of the affected repository. At the affected revision, /bld does not exist at the repository root. The actual bld directories exist under subpaths such as /branches/.../bld, /tags/.../bld, and /trunk/bld.

I ran svnadmin verify, and the repository was successfully verified through the affected revision. I also queried the actual full path of a bld directory using svnlook, and the directory and its files were listed successfully. However, when I queried /bld directly at the repository root, I was able to reproduce the same E160013: File not found error that appears in the SCM-Manager logs.

I also checked the properties on the relevant paths. svn:ignore and svn:mergeinfo were found, but svn:externals was not found on the relevant paths that I checked.

Following your suggestion regarding the root-level directory structure, I added an additional directory at the root level of an affected repository and tested it again. However, the same error still occurred.

Normal SVN operations such as checkout, update, and commit are working correctly. The error is repeatedly recorded in the SCM-Manager logs while browsing the repository through the SCM-Manager Web UI.

Based on these results, could this issue be caused by SCM-Manager passing a root-relative path such as /bld to SVNKit instead of the actual full path, such as /branches/.../bld or /tags/.../bld, during the Web UI browse process?

We are currently using SCM-Manager 3.11.3. Were there any changes or fixes related to SVN repository browsing or path resolution in versions released after 3.11.3? Also, would you recommend upgrading SCM-Manager to the latest version as a possible solution to this issue?

Additionally, is it possible to update the SVN-related core plugin or SVNKit independently, or are these components updated only as part of an SCM-Manager version upgrade?

Regarding the repository export file you requested, unfortunately, due to our company’s security policy, we are not allowed to export or provide the actual SVN repository or source data outside the company. However, if there are any additional diagnostic commands or tests that can be performed without providing the repository data externally, I would be happy to run them and share the results.

Thank you for your help.

4

Additionally, I confirmed that this issue does not occur in all SVN repositories, but only in some repositories. In the affected repositories, the bld directory exists correctly under a subpath, while the SCM-Manager log shows an attempt to access /bld at the repository root, resulting in E160013. Could there be a repository-specific condition, such as its structure or history, that causes the path to be interpreted incorrectly during the SCM-Manager Web UI browse process? I would also like to know whether there are any known conditions or similar cases that could explain why this occurs only with certain repositories.