update: devel/subversion 1.11.0

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

update: devel/subversion 1.11.0

Stefan Sperling-5
For release notes, see:
https://subversion.apache.org/docs/release-notes/1.11.html

There is a known issue with GitHub's SVN bridge: SVN 1.11 clients don't
recognize GitHub's custom April fools SVN server implementation anymore,
due to stricter client-side HTTP/DAV RFC conformance checks. A surprising
number of people were relying on this, but I doubt any OpenBSD users will
care. This will hopefully be fixed at Github's end eventually.
In the meantime, devel/git can be installed as a workaround :)

The following dependencies still package fine with this diff:

devel/cvs2svn
devel/git
devel/kdevelop
devel/p5-SVN-Notify
devel/p5-SVN-Simple
devel/p5-SVN-Web
devel/pysvn
devel/rapidsvn
graphics/netpbm
sysutils/ncal
sysutils/salt
www/trac
x11/kde4/sdk-kioslaves
x11/xfce4/thunar-vcs
x11/xfce4/xfce4-dev-tools

Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/subversion/Makefile,v
retrieving revision 1.168
diff -u -p -r1.168 Makefile
--- Makefile 26 Oct 2018 16:15:44 -0000 1.168
+++ Makefile 10 Nov 2018 08:33:14 -0000
@@ -7,7 +7,7 @@ COMMENT-ruby= ruby interface to subvers
 COMMENT-ap2= apache2 subversion modules
 COMMENT-gnome-keyring= GNOME keyring support for subversion
 
-VERSION= 1.10.3
+VERSION= 1.11.0
 DISTNAME= subversion-${VERSION:S/rc/-rc/}
 PKGNAME-main= subversion-${VERSION}
 FULLPKGNAME-perl= p5-SVN-${VERSION}
@@ -25,7 +25,7 @@ MODRUBY_REV ?= 2.5
 # Work around for SHARED_LIBS not picking up MODRUBY_BINREV from ruby module
 MODRUBY_BINREV= ${MODRUBY_REV:S/.//}
 
-SO_VERSION= 3.0
+SO_VERSION= 4.0
 SVN_LIBS= svn_client-1 svn_delta-1 svn_diff-1 svn_fs-1 \
  svn_fs_base-1 svn_fs_fs-1 svn_fs_util-1 svn_fs_x-1 \
  svn_ra-1 svn_ra_serf-1 svn_ra_local-1 \
Index: distinfo
===================================================================
RCS file: /cvs/ports/devel/subversion/distinfo,v
retrieving revision 1.58
diff -u -p -r1.58 distinfo
--- distinfo 16 Oct 2018 11:09:03 -0000 1.58
+++ distinfo 10 Nov 2018 08:33:43 -0000
@@ -1,2 +1,2 @@
-SHA256 (subversion-1.10.3.tar.bz2) = nw2qyLhK76p3rVTdBatXjsyTnY5y0IwM1PYTFZId2fw=
-SIZE (subversion-1.10.3.tar.bz2) = 8374465
+SHA256 (subversion-1.11.0.tar.bz2) = h8RDRLB0rC6e18qWdfseWxlwUcPe7P5ZNOX2rvv4PlY=
+SIZE (subversion-1.11.0.tar.bz2) = 8490744
Index: pkg/PLIST-gnome-keyring
===================================================================
RCS file: /cvs/ports/devel/subversion/pkg/PLIST-gnome-keyring,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST-gnome-keyring
--- pkg/PLIST-gnome-keyring 14 Jun 2016 08:36:29 -0000 1.4
+++ pkg/PLIST-gnome-keyring 10 Nov 2018 08:49:11 -0000
@@ -1,6 +1,6 @@
 @comment $OpenBSD: PLIST-gnome-keyring,v 1.4 2016/06/14 08:36:29 czarkoff Exp $
-@pkgpath subversion,gnome_keyring
 @conflict subversion-*-gnome_keyring
+@pkgpath subversion,gnome_keyring
 @comment lib/libsvn_auth_gnome_keyring-1.a
 @comment lib/libsvn_auth_gnome_keyring-1.la
 @lib lib/libsvn_auth_gnome_keyring-1.so.${LIBsvn_auth_gnome_keyring-1_VERSION}
Index: pkg/PLIST-main
===================================================================
RCS file: /cvs/ports/devel/subversion/pkg/PLIST-main,v
retrieving revision 1.19
diff -u -p -r1.19 PLIST-main
--- pkg/PLIST-main 23 Apr 2018 20:06:01 -0000 1.19
+++ pkg/PLIST-main 10 Nov 2018 08:49:11 -0000
@@ -1,10 +1,11 @@
 @comment $OpenBSD: PLIST-main,v 1.19 2018/04/23 20:06:01 stsp Exp $
-@newgroup _svnserve:777
-@newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/nonexistent:/sbin/nologin
+@conflict subversion-*-gnome_keyring
 @pkgpath devel/subversion,no_bindings
 @pkgpath devel/subversion,-main,gnome_keyring
 @pkgpath devel/subversion
-@conflict subversion-*-gnome_keyring
+@newgroup _svnserve:777
+@newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/nonexistent:/sbin/nologin
+@rcscript ${RCDIR}/svnserve
 @comment @bin bin/diff
 @comment @bin bin/diff3
 @comment @bin bin/diff4
@@ -21,6 +22,7 @@ bin/fsfs-stats
 @bin bin/svndumpfilter
 @bin bin/svnfsfs
 @bin bin/svnlook
+@bin bin/svnmover
 @bin bin/svnmucc
 @bin bin/svnraisetreeconflict
 @bin bin/svnrdump
@@ -237,4 +239,3 @@ share/pkgconfig/libsvn_ra_svn.pc
 share/pkgconfig/libsvn_repos.pc
 share/pkgconfig/libsvn_subr.pc
 share/pkgconfig/libsvn_wc.pc
-@rcscript ${RCDIR}/svnserve
Index: pkg/PLIST-perl
===================================================================
RCS file: /cvs/ports/devel/subversion/pkg/PLIST-perl,v
retrieving revision 1.8
diff -u -p -r1.8 PLIST-perl
--- pkg/PLIST-perl 14 Jun 2014 10:34:44 -0000 1.8
+++ pkg/PLIST-perl 10 Nov 2018 08:49:11 -0000
@@ -3,6 +3,8 @@
 lib/libsvn_swig_perl-1.a
 lib/libsvn_swig_perl-1.la
 @lib lib/libsvn_swig_perl-1.so.${LIBsvn_swig_perl-1_VERSION}
+libdata/perl5/${MACHINE_ARCH}-openbsd/
+libdata/perl5/${MACHINE_ARCH}-openbsd/perllocal.pod
 libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/
 libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/SVN/
 libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/SVN/Base.pm
Index: pkg/PLIST-python
===================================================================
RCS file: /cvs/ports/devel/subversion/pkg/PLIST-python,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST-python
--- pkg/PLIST-python 10 Oct 2013 09:50:17 -0000 1.9
+++ pkg/PLIST-python 10 Nov 2018 08:49:11 -0000
@@ -2,7 +2,7 @@
 @pkgpath devel/subversion,-python,gnome_keyring
 lib/libsvn_swig_${MODPY_PY_PREFIX}1.a
 lib/libsvn_swig_${MODPY_PY_PREFIX}1.la
-@lib lib/libsvn_swig_${MODPY_PY_PREFIX}1.so.${LIBsvn_swig_py-1_VERSION}
+@lib lib/libsvn_swig_${MODPY_PY_PREFIX}1.so.${LIBsvn_swig_${MODPY_PY_PREFIX}1_VERSION}
 lib/python${MODPY_VERSION}/site-packages/libsvn/
 lib/python${MODPY_VERSION}/site-packages/libsvn/__init__.py
 lib/python${MODPY_VERSION}/site-packages/libsvn/__init__.pyc
Index: pkg/PLIST-ruby
===================================================================
RCS file: /cvs/ports/devel/subversion/pkg/PLIST-ruby,v
retrieving revision 1.10
diff -u -p -r1.10 PLIST-ruby
--- pkg/PLIST-ruby 1 Nov 2017 10:16:53 -0000 1.10
+++ pkg/PLIST-ruby 10 Nov 2018 08:49:11 -0000
@@ -1,12 +1,11 @@
 @comment $OpenBSD: PLIST-ruby,v 1.10 2017/11/01 10:16:53 jeremy Exp $
 @pkgpath devel/subversion,-ruby,gnome_keyring
-@comment lib/ruby/
-@comment lib/ruby/site_ruby/
-@comment lib/ruby/site_ruby/${MODRUBY_LIBREV}/
-@comment lib/ruby/site_ruby/${MODRUBY_LIBREV}/${MODRUBY_ARCH}/
 lib/libsvn_swig_ruby${MODRUBY_BINREV}-1.a
 lib/libsvn_swig_ruby${MODRUBY_BINREV}-1.la
-@lib lib/libsvn_swig_ruby${MODRUBY_BINREV}-1.so.${LIBsvn_swig_ruby-1_VERSION}
+@lib lib/libsvn_swig_ruby${MODRUBY_BINREV}-1.so.${LIBsvn_swig_ruby${MODRUBY_BINREV}-1_VERSION}
+@comment lib/ruby/
+@comment lib/ruby/site_ruby/
+@comment ${MODRUBY_SITEDIR}/
 ${MODRUBY_SITEDIR}/svn/
 ${MODRUBY_SITEDIR}/svn/client.rb
 ${MODRUBY_SITEDIR}/svn/commit-mailer.rb
@@ -20,6 +19,7 @@ ${MODRUBY_SITEDIR}/svn/repos.rb
 ${MODRUBY_SITEDIR}/svn/synchronizer.rb
 ${MODRUBY_SITEDIR}/svn/util.rb
 ${MODRUBY_SITEDIR}/svn/wc.rb
+@comment ${MODRUBY_SITEARCHDIR}/
 ${MODRUBY_SITEARCHDIR}/svn/
 ${MODRUBY_SITEARCHDIR}/svn/ext/
 ${MODRUBY_SITEARCHDIR}/svn/ext/client.a

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Juan Francisco Cantero Hurtado
On Sat, Nov 10, 2018 at 12:47:59PM +0100, Stefan Sperling wrote:
> For release notes, see:
> https://subversion.apache.org/docs/release-notes/1.11.html
>
> There is a known issue with GitHub's SVN bridge: SVN 1.11 clients don't
> recognize GitHub's custom April fools SVN server implementation anymore,
> due to stricter client-side HTTP/DAV RFC conformance checks. A surprising
> number of people were relying on this, but I doubt any OpenBSD users will
> care. This will hopefully be fixed at Github's end eventually.
> In the meantime, devel/git can be installed as a workaround :)

I use the github bridge for ports and src/sys because I don't like how
git manages the local patches. I prefer the CVS/SVN/Mercurial way to
handle the merges (conflicts marks, fix, resolve) instead of the git
stash. Anyway, it's fine with me if you update subversion.

Maybe some users are using private github repos for bootstraping scripts
or golang imports or whatever. I would wait one or two weeks more until
the github fix.

>
> The following dependencies still package fine with this diff:
>
> devel/cvs2svn
> devel/git
> devel/kdevelop
> devel/p5-SVN-Notify
> devel/p5-SVN-Simple
> devel/p5-SVN-Web
> devel/pysvn
> devel/rapidsvn
> graphics/netpbm
> sysutils/ncal
> sysutils/salt
> www/trac
> x11/kde4/sdk-kioslaves
> x11/xfce4/thunar-vcs
> x11/xfce4/xfce4-dev-tools
>

--
Juan Francisco Cantero Hurtado http://juanfra.info

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Stefan Sperling-5
On Sat, Nov 10, 2018 at 09:28:48PM +0100, Juan Francisco Cantero Hurtado wrote:

> On Sat, Nov 10, 2018 at 12:47:59PM +0100, Stefan Sperling wrote:
> > For release notes, see:
> > https://subversion.apache.org/docs/release-notes/1.11.html
> >
> > There is a known issue with GitHub's SVN bridge: SVN 1.11 clients don't
> > recognize GitHub's custom April fools SVN server implementation anymore,
> > due to stricter client-side HTTP/DAV RFC conformance checks. A surprising
> > number of people were relying on this, but I doubt any OpenBSD users will
> > care. This will hopefully be fixed at Github's end eventually.
> > In the meantime, devel/git can be installed as a workaround :)
>
> I use the github bridge for ports and src/sys because I don't like how
> git manages the local patches. I prefer the CVS/SVN/Mercurial way to
> handle the merges (conflicts marks, fix, resolve) instead of the git
> stash. Anyway, it's fine with me if you update subversion.

Github's SVN bridge is a practical April fools joke. Seriously:
https://blog.github.com/2010-04-01-announcing-svn-support/
They just never turned it off...

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Juan Francisco Cantero Hurtado
On Sun, Nov 11, 2018 at 11:52:04AM +0100, Stefan Sperling wrote:

> On Sat, Nov 10, 2018 at 09:28:48PM +0100, Juan Francisco Cantero Hurtado wrote:
> > On Sat, Nov 10, 2018 at 12:47:59PM +0100, Stefan Sperling wrote:
> > > For release notes, see:
> > > https://subversion.apache.org/docs/release-notes/1.11.html
> > >
> > > There is a known issue with GitHub's SVN bridge: SVN 1.11 clients don't
> > > recognize GitHub's custom April fools SVN server implementation anymore,
> > > due to stricter client-side HTTP/DAV RFC conformance checks. A surprising
> > > number of people were relying on this, but I doubt any OpenBSD users will
> > > care. This will hopefully be fixed at Github's end eventually.
> > > In the meantime, devel/git can be installed as a workaround :)
> >
> > I use the github bridge for ports and src/sys because I don't like how
> > git manages the local patches. I prefer the CVS/SVN/Mercurial way to
> > handle the merges (conflicts marks, fix, resolve) instead of the git
> > stash. Anyway, it's fine with me if you update subversion.
>
> Github's SVN bridge is a practical April fools joke. Seriously:
> https://blog.github.com/2010-04-01-announcing-svn-support/
> They just never turned it off...

People have been asking for the same feature to GitLab for years :P


--
Juan Francisco Cantero Hurtado http://juanfra.info

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

George Koehler-2
In reply to this post by Stefan Sperling-5
On Sat, 10 Nov 2018 12:47:59 +0100
Stefan Sperling <[hidden email]> wrote:

> There is a known issue with GitHub's SVN bridge: SVN 1.11 clients don't
> recognize GitHub's custom April fools SVN server implementation anymore,
> due to stricter client-side HTTP/DAV RFC conformance checks. A surprising
> number of people were relying on this, but I doubt any OpenBSD users will
> care. This will hopefully be fixed at Github's end eventually.
> In the meantime, devel/git can be installed as a workaround :)

I don't care.  I don't use svn with GitHub.  If we are waiting for
GitHub to fix their svn bridge, we might be waiting too long.

I installed your 1.11.0 update on amd64, and did a svn checkout (from
the only svn server that I used recently) without problem.

Looks like GitHub's svn bridge is still broken:

$ svn co --depth empty https://github.com/OpenTTD/OpenTTD
svn: E170013: Unable to connect to a repository at URL 'https://github.com/OpenT
TD/OpenTTD'
svn: E175003: The server at 'https://github.com/OpenTTD/OpenTTD' does not suppor
t the HTTP/DAV protocol

--
George Koehler <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Aham Brahmasmi
Hello ports,

Apologies for removing the context, I joined the ports list recently and
do not have stsp's original mail.

I may be wrong here, but I was wondering whether we could change the
home of the _svnserve user to /var/svn from the current /nonexistent.

In other words, could we change from
@newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/nonexistent:/sbin/nologin
to
@newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/var/svn:/sbin/nologin

The idea is that post installation, one has to change the owner of the
/var/svn/reponame directory to _svnserve anyways.

Steps:
$ doas pkg_add subversion
$ cd /var
$ doas mkdir svn
$ cd /var/svn
$ doas svnadmin create reponame
$ doas chown -R _svnserve:_svnserve /var/svn/reponame
$ doas mkdir log
$ doas chown -R _svnserve:_svnserve /var/svn/log

For more context, could I please refer you to my recent mail on misc -
https://marc.info/?l=openbsd-misc&m=154221094309572&w=2.

In case I am missing something or doing something stupid, please feel
free to point it out.

Thanks.

Regards,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Stefan Sperling-5
In reply to this post by George Koehler-2
On Tue, Nov 20, 2018 at 11:15:59PM -0500, George Koehler wrote:
> Looks like GitHub's svn bridge is still broken:
>
> $ svn co --depth empty https://github.com/OpenTTD/OpenTTD
> svn: E170013: Unable to connect to a repository at URL 'https://github.com/OpenT
> TD/OpenTTD'
> svn: E175003: The server at 'https://github.com/OpenTTD/OpenTTD' does not suppor
> t the HTTP/DAV protocol
>

They're working on it: https://svn.haxx.se/users/archive-2018-11/0067.shtml

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Stefan Sperling-5
On Wed, Nov 21, 2018 at 04:00:04PM +0100, Stefan Sperling wrote:

> On Tue, Nov 20, 2018 at 11:15:59PM -0500, George Koehler wrote:
> > Looks like GitHub's svn bridge is still broken:
> >
> > $ svn co --depth empty https://github.com/OpenTTD/OpenTTD
> > svn: E170013: Unable to connect to a repository at URL 'https://github.com/OpenT
> > TD/OpenTTD'
> > svn: E175003: The server at 'https://github.com/OpenTTD/OpenTTD' does not suppor
> > t the HTTP/DAV protocol
> >
>
> They're working on it: https://svn.haxx.se/users/archive-2018-11/0067.shtml

This update has now been committed.

If anyone still has problems with GitHub's SVN bridge, please take
your problem to GitHub, not me. Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Stefan Sperling-5
In reply to this post by Aham Brahmasmi
On Wed, Nov 21, 2018 at 12:18:16PM +0100, Aham Brahmasmi wrote:

> Hello ports,
>
> Apologies for removing the context, I joined the ports list recently and
> do not have stsp's original mail.
>
> I may be wrong here, but I was wondering whether we could change the
> home of the _svnserve user to /var/svn from the current /nonexistent.
>
> In other words, could we change from
> @newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/nonexistent:/sbin/nologin
> to
> @newuser _svnserve:777:_svnserve:daemon:SVN Daemon:/var/svn:/sbin/nologin
>
> The idea is that post installation, one has to change the owner of the
> /var/svn/reponame directory to _svnserve anyways.

I like your idea. I suppose /var/svn is a sane default path, and there
are already other cases where other parts create directories in /var.

I'll note though that /var/svn won't work with an Apache HTTPD server
chrooted to /var/www -- but chroot requires special steps anyway and
having /var/svn around for just svnserve won't hurt.

Would you be able to submit a diff to the port which implements
this idea?


> Steps:
> $ doas pkg_add subversion
> $ cd /var
> $ doas mkdir svn
> $ cd /var/svn
> $ doas svnadmin create reponame
> $ doas chown -R _svnserve:_svnserve /var/svn/reponame
> $ doas mkdir log
> $ doas chown -R _svnserve:_svnserve /var/svn/log
>
> For more context, could I please refer you to my recent mail on misc -
> https://marc.info/?l=openbsd-misc&m=154221094309572&w=2.
>
> In case I am missing something or doing something stupid, please feel
> free to point it out.
>
> Thanks.
>
> Regards,
> ab
> ---------|---------|---------|---------|---------|---------|---------|--
>

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Aham Brahmasmi
Danke Stefan for your response.

> I like your idea. I suppose /var/svn is a sane default path, and there
> are already other cases where other parts create directories in /var.

Yes, the Postgresql port uses /var/postgresql.

I tried to find a best practice for the subversion directory. Most volks
seemed to use /var/svn.

> Would you be able to submit a diff to the port which implements
> this idea?

Unfortunately, I would not be able to as of now. But sometime in future,
I do hope to contribute. I am sorry for this.

While trying to determine the best practices, I encountered a few ideas.
Would it be possible for volks to please share their thoughts on them:
1) Is it a good idea to make a separate disklabel partition /var/svn?
2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab
options to mount /var/svn?
3) What is a good svn repository backup routine? Any gotchas that should
be kept in mind?

Regards,
ab
---------|---------|---------|---------|---------|---------|---------|--

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Stefan Sperling-5
On Sun, Nov 25, 2018 at 11:45:08AM +0100, Aham Brahmasmi wrote:

> Danke Stefan for your response.
>
> > I like your idea. I suppose /var/svn is a sane default path, and there
> > are already other cases where other parts create directories in /var.
>
> Yes, the Postgresql port uses /var/postgresql.
>
> I tried to find a best practice for the subversion directory. Most volks
> seemed to use /var/svn.
>
> > Would you be able to submit a diff to the port which implements
> > this idea?
>
> Unfortunately, I would not be able to as of now. But sometime in future,
> I do hope to contribute. I am sorry for this.

No problem. I'll see if I can find time to tweak the port myself.

> While trying to determine the best practices, I encountered a few ideas.
> Would it be possible for volks to please share their thoughts on them:
> 1) Is it a good idea to make a separate disklabel partition /var/svn?

Depends on your storage needs and configuration.

> 2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab
> options to mount /var/svn?

Don't use softdep! It risks repository corruption during a system crash.

Use the same mount flags as the defaults for /var.

> 3) What is a good svn repository backup routine? Any gotchas that should
> be kept in mind?

The biggest concern is that backups should be created immediately after
a change has been committed, and that your backup should preferrably go to
a different physical machine. Use the post-commit hook to trigger a backup
(and the post-revprop-change hook, too, if your repository is configured
to allow revprop changes).

As for getting a copy of repository data, there are a number of options.

The fastest and smallest backup is provided by:
  svnadmin hotcopy --incremental /var/svn/repo /data/backup/repo
It is safe to run this command in a post-commit hook.
But a local mount point for the destination is required. Incremental hotcopy
relies on file sizes and last-modified timestamps recorded in the filesystems
of source and destination.
If the destination is a network drive, make sure clocks between machine stay
in sync. No harm will be done when the clocks are out of sync, but it can
take a lot more time if timestamps don't match since data might be copied
redundantly.

If you need to backup a repository across a network connection, then
take a look at 'svnsync' (requires a second SVN server) and 'svnrdump'
(backup requires read-access over network, backup can be restored
locally with 'svnadmin load').

There is also 'svnadmin freeze' but that is intended for use with an
underlying filesystem which supports snapshots, and OpenBSD does not
support any such filesystem.

Reply | Threaded
Open this post in threaded view
|

Re: update: devel/subversion 1.11.0

Aham Brahmasmi
Danke Stefan for your very helpful response. I apologize for the delay
in my response.

> > 2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab
> > options to mount /var/svn?
>
> Don't use softdep! It risks repository corruption during a system crash.
>
> Use the same mount flags as the defaults for /var.

I went back to the man page for mount(8) [1] to try to understand why
I might have chosen softdep as a mount option.

The explanation for softdep includes the following line:
"
Instead of metadata being written immediately, it is written in an
ordered fashion to keep the on-disk state of the file system consistent.
"

I am a relative newcomer, so I inferred softdep as better because it
helped "keep the on-disk state of the file system consistent". Clearly,
I parsed it incorrectly if softdep can cause repository corruption
during a crash.
 

> > 3) What is a good svn repository backup routine? Any gotchas that should
> > be kept in mind?
>
> The biggest concern is that backups should be created immediately after
> a change has been committed, and that your backup should preferrably go to
> a different physical machine. Use the post-commit hook to trigger a backup
> (and the post-revprop-change hook, too, if your repository is configured
> to allow revprop changes).
>
> As for getting a copy of repository data, there are a number of options.
>
> The fastest and smallest backup is provided by:
>   svnadmin hotcopy --incremental /var/svn/repo /data/backup/repo
> It is safe to run this command in a post-commit hook.
> But a local mount point for the destination is required. Incremental hotcopy
> relies on file sizes and last-modified timestamps recorded in the filesystems
> of source and destination.
> If the destination is a network drive, make sure clocks between machine stay
> in sync. No harm will be done when the clocks are out of sync, but it can
> take a lot more time if timestamps don't match since data might be copied
> redundantly.
>
> If you need to backup a repository across a network connection, then
> take a look at 'svnsync' (requires a second SVN server) and 'svnrdump'
> (backup requires read-access over network, backup can be restored
> locally with 'svnadmin load').
>
> There is also 'svnadmin freeze' but that is intended for use with an
> underlying filesystem which supports snapshots, and OpenBSD does not
> support any such filesystem.

Danke for the exhaustive backup advice. Reading the useful SVN Redbook
[2] highlighted some more distinctions between these approaches.

Regards,
ab
[1] - https://man.openbsd.org/man8/mount.8
[2] - http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
---------|---------|---------|---------|---------|---------|---------|--