On Sat, Feb 11, 2023 at 2:46 PM Bo Berglund wrote:
> Follow-up:
>
> 1) I did a manual run with the command including --steal-lock and it showed
> there was a stale lock that it could take over and perform the update.
> So this seems to be the way to do it.
Stealing locks should *not* be done by
On Sat, 11 Feb 2023 18:56:34 +0100, Bo Berglund wrote:
>Thanks Pavel!
>I just want to check so that I get it right:
>
>1. Modify the command to use --steal-lock like this in the script (all on one
>line):
>E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize
>--steal-lock
>--sync-
On Sat, 11 Feb 2023 19:50:41 +0400, "Pavel Lyalyakin via users"
wrote:
>> E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize
>> --sync-username syncuser https://backupservername/svn/pcb
>> https://agiengineering/svn/pcb
>> Failed to get lock on destination repos, currently held b
On Sat, Feb 11, 2023 at 7:23 PM Bo Berglund wrote:
>
> I have a backup system set up for our VisualSVN server running on Windows
> Server
> 2016. It consists of a batch file scheduled to run nightly on the SVN server.
>
> The batch uses a series of commands, one for each of the backed up
> repos
I have a backup system set up for our VisualSVN server running on Windows Server
2016. It consists of a batch file scheduled to run nightly on the SVN server.
The batch uses a series of commands, one for each of the backed up repositories
and has been in place from 2018.
Now when checking the sta
