On Thu, Dec 13, 2018 at 07:18:23AM -0600, Tom Browder wrote:
> Sorry, Nico, I probably didn’t use the correct terms in my problem
> description. Basically the subversion repos on my remote server were
> current as of about six months ago when they were established there
> and a hotcopy was made.
You should reconsider your backup strategy.
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' which is intended for use with an
underlying filesystem which supports snapshots (e.g. ZFS). You can
freeze the repository while a snapshot is created, and then copy
data from that snapshot however you want.
> There have been few updates since, so is the hotcopy of value or not,
> history wise?
Only you can decide whether the history of your data is valuable to you.
> I started to update on one and am getting these messages (which you
> warned me about):
>
> Clean Up: Failed to run the WC DB work queue associated with
> 'C:\Users\Tom\Documents\0-mydocs-svn', work item 636 (file-install
> Personal/TomB/sto/Misc/llftpar2.exe 1 0 1 1) Can't open file
> 'C:\Users\Tom\Documents\0-mydocs-svn\.svn\pristine\7e\7eddb1479c338c0a0fb4a08e21e2b81a8d6c1b61.
> svn-base': The system cannot find the file specified.
This error means the working copy is corrupt. This error has nothing to do
with the repository. The working copy's work queue contains instructions to
copy a temporary file into the area where you see the files you work with.
One possible reason is that an operation (probably an update) was interrupted
in a bad way, i.e. not by a 'Cancel' button but because SVN crashed.
Another possibility is that you moved this working copy between machines
and somehow lost the temporary files in that process.
Generally, SVN's design considers working copies as disposable
because they can always be checked out again, Your resistence to
transferring your data again is working against that design assumption.
> Is there anything I can do to fix something like that? Or do I have
> to go through creating new repos and populating them from he original
> repo files and dirs?
I'll note that you still haven't fixed your problem which we first
heard about last Sunday. Would it take you more than a week to transfer
the data? Maybe you should just do something that allows you to move on,
instead of waiting until you find a potentially perfect solution?
Received on 2018-12-14 12:26:45 CET