Re: update: devel/subversion 1.11.0
On Fri, Nov 23, 2018 at 01:45:06PM +0100, Stefan Sperling wrote: > 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. FYI, GitHub fixed the problems. The bridge is working again. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: update: devel/subversion 1.11.0
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 -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
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.
Re: update: devel/subversion 1.11.0
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 -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
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 > -|-|-|-|-|-|-|-- >
Re: update: devel/subversion 1.11.0
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.
Re: update: devel/subversion 1.11.0
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
Re: update: devel/subversion 1.11.0
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 -|-|-|-|-|-|-|--
Re: update: devel/subversion 1.11.0
On Sat, 10 Nov 2018 12:47:59 +0100 Stefan Sperling 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
Re: update: devel/subversion 1.11.0
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
Re: update: devel/subversion 1.11.0
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...
Re: update: devel/subversion 1.11.0
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
update: devel/subversion 1.11.0
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
--- Makefile26 Oct 2018 16:15:44 - 1.168
+++ Makefile10 Nov 2018 08:33:14 -
@@ -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
--- distinfo16 Oct 2018 11:09:03 - 1.58
+++ distinfo10 Nov 2018 08:33:43 -
@@ -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 - 1.4
+++ pkg/PLIST-gnome-keyring 10 Nov 2018 08:49:11 -
@@ -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 - 1.19
+++ pkg/PLIST-main 10 Nov 2018 08:49:11 -
@@ -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 - 1.8
+++ pkg/PLIST-perl 10 Nov 2018 08:49:11 -
@@ -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/
li
