On Sat, 28 Dec 2024 09:02:16 -0600, Ryan Carsten Schmidt <subversion-2...@ryandesign.com> wrote:
(NOTE: I had to open the html attachment externally to see this reply, my text only newsreader did not show it, just as an attached file.... So I added its text verbatim here for future readers of the group archives.) Thanks for your input, it arrived while I was busy composing my last response without knowledge of these comments and advice... >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. If it is not a server how can I browse its content? > 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. Well, subversion was part of the VisualSVN package when I converted our 16+ years old CVSNT repositories back in 2017. I don't know how integrated they are so I dare not mess with it. > 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. So after I made a file system xcopy of the cmp repo dir to cpmcpy using an admin command line, the two trees were exactly on the byte the same length, i.e. identical. I also managed after some trial/error runs check the new and original repo via info and they displayed the same including the UUID. > >> 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. OK, that is what I did and then tested loading the dump file, whereupon I got the error message about a hook missing. It is also missing in the original repo so I guess it is not used except during a dumpfile load... See my previous message about what I did to get there. -- Bo Berglund Developer in Sweden
