Den tis 7 jan. 2025 kl 22:08 skrev Bo Berglund <bo.bergl...@gmail.com>:
> > This is how the execution went (long lines are wrapped by my newsreader): > > H:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize > --sync-username syncuser https://svn.mydomain.com/svn/pc > https://agiengineering/svn/pc > > Failed to get lock on destination repos, currently held by > 'AGIENGINEERING:4b3622e3-1724-2d47-9cdd-82690ad1fe60' > > repeated 10 times.... > > Failed to get lock on destination repos, currently held by > 'AGIENGINEERING:4b3622e3-1724-2d47-9cdd-82690ad1fe60' > > svnsync: E000022: Couldn't get lock on destination repos after 10 attempts > > So I also tested on another repository: > > H:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize > --sync-username syncuser https://svn.mydomain.com/svn/pcb > https://agiengineering/svn/pcb > > Here there are no errors at all... > > 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 It seems someone already prepared for this situation in your script so just un-rem the first of the two lines and add a rem to the second line to force --steal-lock this time. Then revert the change for the regular scheduled sync. The reason for all this is probably that a previous sync was interrupted halfway through while the lock was still set on the target repo. >> And it is a single operation on the main server that runs these sync > operations. > >> > There is one TaskScheduler call to run the batch file that sets up the call > string and then applies it to each repository in turn. > > Unfortunately there is no error handling in the batch file as yet. > I don't know how to do that in a Windows environment, in Linux I have done > it > often and there I can make a curl call to my webserver where I have a php > script > that can send me an email with the supplied text. > Curl is available on Windows and you can probably do the same in a BAT file. Else look at monitoring the Event log in Windows, you would probably see some errors there (at least if you set a proper error exit code using the exit command (see exit /?) in case of errors). > > >> 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. Cheers, Daniel
