On Thu, 8 Aug 2019 23:12:22 +0200, "Bo Berglund" <bo.berglund_at_gmail.com> wrote:
>> Subversion keeps track of repository identities not using URLs (since URLs can change, and since
>> you could even have multiple URLs that refer to a single repository) but using UUIDs which are
>> assigned at repository creation time. Since the UUIDs of the master and the mirror aren't changing
>> there shouldn't be a problem.
>
>Thanks a lot for your explanation!
>It makes things much easier.
>I have created and configured the svn domain with ddcli set up to manage the IP updates now.
>My initial test on the backup server shows that it connects properly from a browser even using the new
>domain name (same IP address).
>
>So I am probably good to go as soon as I have figured out how to obtain a signed cert via certbot
>without first having to open up the site to port 80 (http://) access...
>I had to do that when I used certbot for my other site on the same server. During certbot's process
>it seems to need access via port 80 to validate the site location.
>And I don't want to open it even for a very short time...
>
>But this is of course not a subversion problem, rather a certbot and apache one.
UPDATE:
So now I have used certbot on the backup server to get a certificate covering the new svn.xxxx domain address.
Installed it into Apache by editing the sites-available/default-ssl.conf file where the self-signed cert was defined.
I used the full path to the /etc/letsencrypt/live folder where the cert was placed.
After reloading apache2 everything seemed to work, like accessing the web interface of the repositories
both from my local PC and from across the world where the production server is located.
The padlock symbol which was previously marked as insecure is now green!
I could check out a wc of a project from the backup server on the master server using the command line.
BUT! Now svnsync has stopped working.....
I have edited the batch file that runs the backup process and replaced the subdomain "home" with "svn"
in all svnsync calls.
It should have updated the backup server with a single revision on a test project overnight but it did not.
And when I look at the log file from the sync batch file it shows it to still be running hours afterwards.
Normally it takes less than 30 min to complete depending on the number of changes to handle.
Maybe it is waiting for some user input?
So I looked at TaskManager and found svnsync to still be in a running state. Used TaskManager to end it.
Then on a command line on the main server I issued the command at the top of the batch file to see what could have gone wrong.
This is what I see:
H:\>svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
Password for 'Bosse': *********
Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
Username: bosse
Password for 'bosse': *********
svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
Only the syncuser user may change revision properties
"syncuser" is the synchronization user I have created on the backup server to write to the repo (it is otherwise read only).
It has been put into the master server as the sync user during initialization of svnsync.
It is the only backup server user with write permissions.
So I tried to repeat the command and planned to enter "syncuser" at the second login prompt,
but this time the prompts did not re-appear so I got the error message directly:
svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
Only the syncuser user may change revision properties
How can I force a different svnsync user than the one apparently erroneously cached somewhere when I test svnsync on the command line?
Any other suggestions?
Received on 2019-08-11 10:30:24 CEST