Recently I bought a Synology DS1821+ to complement a pair of
long-in-the-tooth HP N40L micro servers running Windows.
Although I originally bought it just for storage and "real"
RAID, I found it such a delightful device that I decided that it
should replace the micro servers completely. Prior to this I've
never really used Docker, but the Synology DiskStation Manager
(DSM) software makes it a breeze - in no time at all I had
Jenkins and Gitea running on it via official packages, and a
third party for SVN as I still have both a legacy and a
"current" repository, the latter one that I'm piecemeal
converting to git.
The only problem was, the truly ancient VB6 repository would
load fine, but the "current" C# one failed when trying to access
it:
Could not open the requested SVN filesystem
I then had a rather frustrating session trying assorted
fruitless attempts to get the repository accessible, copying it
directly, doing svnadmin dump and svnadmin load, deleting
Windows-based hooks, etc etc without success.
Seeing the light
Worried that the original repository was corrupt, I finally did
a svnadmin verify on it, which passed with flying colours.
However, when I tried the same command on my most recent clone,
instead of the generic error I'd been getting with other
commands I got something specific and helpful.
svnadmin: E160043: Expected FS format between '1' and '7'; found format '8'
Now we're getting somewhere! It appears that the third party
image I'm using isn't using an up to date version of SVN, but
1.9.7 from 6 years ago. Alas this blog doesn't support emoji
otherwise there'd be a facepalm here for sure, both for this
image being woefully out of date, and for me forgetting I wrote
about how I upgraded my repository from an older
version some years back.
Making it go
When you create a repository via svnadmin create, there is a
--compatible-version switch you can use to force an older
version. So back on the Windows box I created a new repository,
using the 1.7 format.
svnadmin create clone --compatible-version 1.7
I then loaded in a previous dump
svnadmin load clone < cyotekdump.svn
Once done, I zipped up the repository, dropped it on the NAS,
deleted the "broken" clone, and extracted the zip in-situ. Then
I re-ran the verify command and...
Huzzah! And the web interface works too.
Closing Notes
Of course, once you look at the Edge and SSH screenshot you can
see the same error code is present in both, not that I know SVN
error codes off the top of my head! In addition I only used Edge
to create the screenshots for this post, originally my testing
was with Firefox - and this didn't show the XML at all, only the
error text.
Although I have this working, it seems rather pointless having
this shiny new device and then installing software on it that is
obsolete and so I need to find a newer image. (Of course, I
really should focus on migrating away from SVN as well!)
But I haven't blogged for a very long time and who knows, this
particular information might help someone else down the line.
All content Copyright (c) by Cyotek Ltd or its respective writers. Permission to reproduce news and web log entries and other RSS feed content in unmodified form without notice is granted provided they are not used to endorse or promote any products or opinions (other than what was expressed by the author) and without taking them out of context. Written permission from the copyright owner must be obtained for everything else. Original URL of this content is https://www.cyotek.com/blog/resolving-svn-error-could-not-open-the-requested-svn-filesystem?source=rss.
