On Tue, 7 Jan 2025 22:20:59 +0100, Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote:
>> In the batch file the command is created at the start and then used for all >> repos going down the file. Here is how it is defined (again wrapped lines): >> >> rem If a repository is not synced due to a lock problem, then use >> --steal-lock >> in a manual command >> >> rem SET SYNCCMD="C:\Program Files\VisualSVN Server\bin\svnsync.exe" >> synchronize >> --steal-lock --sync-username syncuser >> >> SET SYNCCMD="C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize >> --sync-username syncuser >> >> What looks like a commented out suggestion about --steal-locks may or may >> not >> apply here, what does it mean an how to use it? >> > >Yes, --steal-lock would be the solution here. You should read up on the SVN >Book, see the section "svnsync Bookkeeping" for a more detailed >explaination: >https://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync I looked at the svnbook and it mentions the needed hooks so I checked them: I found the pc start-commit being a symlink to a start-commit that looks like this and is common to all repos: --------------------- #!/bin/sh # Bo Berglund 2018-03-25 USER="$2" if [ "$USER" = "syncuser" ]; then exit 0; fi echo "Only the syncuser user may commit new revisions" >&2 exit 1 -------------------- And the other hook pre-revprop-change is also a symlink to a common script with this content, only difference is where the user appears on the command line: -------------------- #!/bin/sh # Bo Berglund 2018-03-25 USER="$3" if [ "$USER" = "syncuser" ]; then exit 0; fi echo "Only the syncuser user may change revision properties" >&2 exit 1 -------------------- Since they are one and the same script for all synced repos this could not be the problem.... But maybe this passage in svnbook is: [quote] The svnsync synchronize subcommand will peek into the special revision properties previously stored on the target repository and determine how much of the source repository has been previously mirrored—in this case, the most recently mirrored revision is r0. Then it will query the source repository and determine what the latest revision in that repository is. Finally, it asks the source repository's server to start replaying all the revisions between 0 and that latest revision. As svnsync gets the resultant response from the source repository's server, it begins forwarding those revisions to the target repository's server as new commits. [/quote] Since there has been "stuff" done to the source repo due to the failure to get all latest revisions I suspect that the revision numbers now are in disarray... And that might have happened more than a year ago without affecting anything except the sync between source and mirror on this single repo... If that is the case then it might be a problem going forward except by starting over with this repository by creating a new recipient repo. If I create a new empty target repository on the mirror server and configure it to be used for syncing, then how long will it take to do the initial sync? The problem is that it is VERY big (14 GB) and the server and mirror are separated by the Atlantic so all comm need to be going through the internet etc... Is it not possible to load a synced repo using an initial dump file from the source and so load the mirror locally without having to worry about connectivity issues during the massive start operation? > >> >> >> HOW to fix this? >> > >> >> Could I proceed like this: >> >> >> >> 1- Make a repo dump on the main server and load that into the mirror. >> >> That should bring the mirror to rev 4518 (same as main) >> > >> >> 2- Check out the involved 3 projects fresh from the main repo >> >> >> >> 3- Using the emailings as base commit the same files as are listed there >> >> Thus recreating the 10 revisions that are missing. >> >> >> >> 4- Perform a manual sync to the mirror repo to bring that to rev 4528 >> > >I would not do a manual dump/load but rather resolve the lock and do an >svnsync syncronize-run to bring the repo up to the same revision as main. OK, but now I have done the above and on the source it looks all OK, but not on the mirror.... So restarting the mirroring seems like the only way to go now.... -- Bo Berglund Developer in Sweden
