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.
