svn export failing using file schema under v1.10

[Sobo77]

Hi,

I have posted details of the following here while I investigate what's happening.

I've looked through the current bugs but have not found anything similar. It is a few years since I last looked at the documentation, so I also going through what's available to see if there is anything obvious I have missed.


Today I noticed that the exports performed as part of a regular back-up are now failing following the upgrade from v1.9.7-2 to v1.10.0-1 performed on 2018-04-24


Platform:
Cygwin 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin

Repository: Typical example:
Path: /var/repos/svn/<repos_name>
UUID: 80441a15-f459-49e5-accb-cdeddae00d91
Revisions: 2336
Repository Format: 5
Compatible With Version: 1.8.0
Repository Capability: mergeinfo
Filesystem Type: fsfs
Filesystem Format: 6
FSFS Sharded: yes
FSFS Shard Size: 1000
FSFS Shards Packed: 0/2
FSFS Logical Addressing: no
Configuration File: /var/repos/svn/<repos-name>/db/fsfs.conf

svn, version 1.10.0 (r1827917)
compiled Apr 22 2018, 17:20:30 on x86_64-unknown-cygwin


The backup is performed as an export of each repository. The export is performed on the server to a local path for replication of the export elsewhere.

The export jobs have run without error for a number of years working through a number of upgrades of subversion without issue. The repositories are plain vanilla implementations with no customisation scripts. Standard svn commands are used, call vrom shell scripts.

The last successful export was the last one before the upgrade, first failure is for the first export after the upgrade.


M.O.

Export task starts, and creates the target folder(s), but fails when setting the permission on the first file with an error of the form:

svn: E000002: Can't set permissions on <full-file-path>
svn: E000002: Can't set permissions on <full-file-path>: No such file or directory


The named file does not appear in the folder, but two two working temp files are present in the form:

svn-XXXXXX

Both of these files are a copy of <full-file-path>, one of which does not have the data in the $Id: field.

The permissions on the folders are no different from previous exports, and writes to the target folder are successful.

The export creates the folder structure, but fails on the first file it encounters.

Exit code of 1.

I have quickly skimmed the release notes, but I see no mention of a requirement to upgrade the file store for theses particular versions.

There may be an obvious cause in which case I will post information here.


Many thanks.

[Johan Corveleyn]

Post by Sobo77
Hi,
I have posted details of the following here while I investigate what's happening.
I've looked through the current bugs but have not found anything similar. It
is a few years since I last looked at the documentation, so I also going
through what's available to see if there is anything obvious I have missed.
Today I noticed that the exports performed as part of a regular back-up are
now failing following the upgrade from v1.9.7-2 to v1.10.0-1 performed on
2018-04-24
Cygwin 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
Path: /var/repos/svn/<repos_name>
UUID: 80441a15-f459-49e5-accb-cdeddae00d91
Revisions: 2336
Repository Format: 5
Compatible With Version: 1.8.0
Repository Capability: mergeinfo
Filesystem Type: fsfs
Filesystem Format: 6
FSFS Sharded: yes
FSFS Shard Size: 1000
FSFS Shards Packed: 0/2
FSFS Logical Addressing: no
Configuration File: /var/repos/svn/<repos-name>/db/fsfs.conf
svn, version 1.10.0 (r1827917)
compiled Apr 22 2018, 17:20:30 on x86_64-unknown-cygwin
The backup is performed as an export of each repository. The export is
performed on the server to a local path for replication of the export
elsewhere.
The export jobs have run without error for a number of years working through
a number of upgrades of subversion without issue. The repositories are plain
vanilla implementations with no customisation scripts. Standard svn commands
are used, call vrom shell scripts.
The last successful export was the last one before the upgrade, first
failure is for the first export after the upgrade.
M.O.
Export task starts, and creates the target folder(s), but fails when setting
svn: E000002: Can't set permissions on <full-file-path>
svn: E000002: Can't set permissions on <full-file-path>: No such file or directory
The named file does not appear in the folder, but two two working temp files
svn-XXXXXX
Both of these files are a copy of <full-file-path>, one of which does not
have the data in the $Id: field.
The permissions on the folders are no different from previous exports, and
writes to the target folder are successful.
The export creates the folder structure, but fails on the first file it encounters.
Exit code of 1.
I have quickly skimmed the release notes, but I see no mention of a
requirement to upgrade the file store for theses particular versions.
There may be an obvious cause in which case I will post information here.

This came up on #svn on irc yesterday too. It seems to be a problem
with the cygwin build. See:

https://www.cygwin.com/ml/cygwin/2018-04/msg00288.html
https://www.cygwin.com/ml/cygwin/2018-04/msg00289.html

For now, I think the only thing you can do is downgrade your cygwin
svn client to 1.9.7 until a new cygwin package is released that fixes
this.

[Johan Corveleyn]

Post by Sobo77
Many thanks.
P.S.
A little thank you to all involved for your work on Subversion over the
years.

I'm gladly forwarding your reply to the list (you replied only to me).
You're welcome :-).