On Dec 28, 2024, at 05:14, Bo Berglund wrote:

You could do a trial run on a local machine instead of the server.
I can't do that since I don't have another Windows machine with a Subversion
server...

All my other devices except my laptop are Linux boxes.

Your Windows laptop is sufficient, if it has enough disk space. All you need is Windows and Subversion and a copy of the July backup of one or more of the repositories that you want to test. You don't need to bother configuring it as a server.

My point was just that you usually want to test things in a non-production environment before doing it in production. But your idea to do it on the production server with a separate testing copy of the July backup is fine too.


The Windows Server 2016 runs VisualSVN 3.7
and it uses svn version 1.9.7 (r1800392)

I know that there are upgrades but I have never understood how to do the upgrade
while protecting our data. And now it is a really long step from where we are to
the current version....

It should be fine to just install a newer Subversion on the server, from the same distributor as you originally used. It should be able to read your old repositories just fine.

Sometimes new versions of Subversion introduce more efficient repository storage or new features which require you to dump and load the repository to take advantage of them. But if you don't need those new features or care about higher disk space usage then you can skip that. 


Is it possible to do an in place "clone" of one of my smaller repositories with
missing changes to a separate repo which has all the same content but a
different name?

If the *repo name* is part of the dumpfile *content* so it must be applied to
the same name repository then this would not work of course...

Repositories don't have a name. They're just referred to by their path on disk. They do also have a UUID to help you distinguish them. The repository UUID is also recorded in any dump file you make of that repository and Subversion won't let you restore a dump file to a repository that doesn't have the matching UUID. Copying a repository will of course copy its UUID so there should be no problem doing the test on a copy of the repository. 


If the dump file I have for the original repository *can* be used on the clone
instead with the suggested commands in a cmd window then I can do a real test
before I touch the actual repositories...

In that case what would be the best approach to copy the repository?

A repository is just a directory of files on disk. Since nothing should be accessing the July backup since you've disabled the server processes, a simple filesystem copy using Windows Explorer or the command line or any other way that you usually copy directories is fine. 

Reply via email to