On Thu, 8 Aug 2019 23:12:22 +0200, "Bo Berglund" <bo.bergl...@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?

Reply via email to