On Mon, 23 Dec 2024 14:13:57 +0100, Timofei Zhakov <t...@chemodax.net> wrote:

>> 2) Is there a load command version where one specifies the file other than
>> piping a cat to it? What happens with binary files in this cat operation?
>>
>
>Yes, there is an option to pass the path to the dumpfile instead:
>
>  -F [--file] ARG          : read from file ARG instead of stdin
>
>`svnadmin load -F dumpfile.dump` should work for you.
>
>However, I'm not sure if it is available in the version 1.9.7. You may
>check the help on your environment using the `svnadmin load --help`
>command.
>
>Also `cat` works badly with PowerShell, because it tries to convert the
>encoding, which corrupts the dumpfile.

This is getting a bit confusing for me, never done this before...

I have now successfully created the 8 dump files on the Linux mirror server for
the repos that had higher revision numbers than the old server after restore
from backup.

They have been transferred to the remote Windows server via ftp after being
compressed to gz files (to avoid any FTP meddling with the content).
On location they are in a "restore" directory and now I need to execute the load
command for each such dump file. All via Remote Desktop on Windows.

The VisualSVN repository root is E:\SVNREPOS where there are the 11 total
repositories as subdirectories. Not all of them need the update.

So my dump files are now in:
 E:\BACKUPS\SVN\agisvn\2024-12-22\

and the repositories are in:
 E:\SVNREPOS\

I figured that I should do everything in a command window located in the dump
file directory - not powershell, just cmd.

So:

cd E:\BACKUPS\SVN\agisvn\2024-12-22\

svnadmin load -F dumpfilename E:\SVNREPOS\repositoryname

And the last line repeated with the dumpfilename and repositoryname pairs
changed for all the 8 dumpfiles.

Is this the correct procedure?

BTW: it seems like the -F argument is missing, the help shown when I did this:
svnadmin load --help

was this:

----------------------------------------------------------------------------
H:\>svnadmin load --help
load: usage: svnadmin load REPOS_PATH

Read a 'dumpfile'-formatted stream from stdin, committing
new revisions into the repository's filesystem.  If the repository
was previously empty, its UUID will, by default, be changed to the
one specified in the stream.  Progress feedback is sent to stdout.
If --revision is specified, limit the loaded revisions to only those
in the dump stream whose revision numbers match the specified range.

Valid options:
  -q [--quiet]             : no progress (only errors to stderr)
  -r [--revision] ARG      : specify revision number ARG (or X:Y range)
  --ignore-uuid            : ignore any repos UUID found in the stream
  --force-uuid             : set repos UUID to that found in stream, if any
  --ignore-dates           : ignore revision datestamps found in the stream
  --use-pre-commit-hook    : call pre-commit hook before committing revisions
  --use-post-commit-hook   : call post-commit hook after committing revisions
  --parent-dir ARG         : load at specified directory in repository
  --bypass-prop-validation : bypass property validation logic
  -M [--memory-cache-size] ARG : size of the extra in-memory cache in MB used to
                             minimize redundant operations. Default: 16.
                             [used for FSFS repositories only]
------------------------------------------------------------------------------

So it seems like this svnadmin does not actually have an -F argument...

Do I really have to *pipe* a cat of the dumpfile into svnadmin?
In that case what is the Windows version of cat?


So I looked in the RedBean "manual" and found this:

$ svnadmin load /var/svn/restored < repos-backup

<<< Started new txn, based on original revision 1
     * adding path : test ... done.
     * adding path : test/a ... done.

where they place the dumpfile (repos-backup) last with a < char in front of it.
Does this work on Windows? If so is this correct for this job:

svnadmin load E:\SVNREPOS\repositoryname < dumpfilename

I don't want to do this erroneously and screw up the repositories....

TIA

-- 
Bo Berglund
Developer in Sweden

Reply via email to