You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Morin, Michael" <Mi...@maine.gov> on 2022/05/18 13:46:25 UTC
Moving the entire SVN instance to a newer Windows server
We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server. Is there a simpler way to do this other than moving each repository one by one? I have over 170 repositories that I need to migrate to the new server. Can the entire SVN instance be backed up and restored....or copied over by some similar method?
Mike Morin
Senior Programmer Analyst
MaineIT, Department of Administrative and Financial Services
(207)592-6134
Re: Moving the entire SVN instance to a newer Windows server
Posted by Daniel Sahlberg <da...@gmail.com>.
Den sön 22 maj 2022 kl 14:41 skrev Nico Kadel-Garcia <nk...@gmail.com>:
> On Sun, May 22, 2022 at 4:24 AM Andreas Stieger <An...@gmx.de>
> wrote:
> >
> > Hi,
> >
> > On 5/18/22 16:54, Mark Phippard wrote:
> > > If you can use the same DNS hostname for the new server there will be
> > > no impact on your clients
> >
> >
> > Except for possibly a change server-side certificate which may have
> > changed (and not properly verified before). Can be addressed with
> > testing, and it helps to use a service name instead of a host name.
> >
> > If you are looking to make this seamless, you can set up replication and
> > write-through proxying as you move the configuration and scripts first.
>
> Why would you want to move a Subversion server to a Windows system?
>
Why not, if it suits the needs of the users? In our case (I'm not OP), we
are a Windows shop with plenty of Windows servers but no pre-existing
Linux/Unix/BSD servers. We selected one of the commercial offerings on
Windows: For the commercial support; To support their work with Subversion;
For the additional nice-to-haves features (one-click Active Directory
authentication, replication, backup). We could have added a new Linux
server and configured everything by hand but to us it made more sense to
install it next to our other applications where all our admins feel
confident.
There are real performance tuning issues for either httpd or svn+ssh
> based access which are more easily handled in a Linux or UNIX
> environment, and high reliability and backup setups far more difficult
> to resolve in a Windows environment.
>
Why would it be more difficult to setup a HA and backup solution on
Windows? (I'm not counting commercial add-ons here).
Kind regards,
Daniel
Re: Moving the entire SVN instance to a newer Windows server
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, May 22, 2022 at 12:02 PM Andreas Stieger <An...@gmx.de> wrote:
>
>
> On 5/22/22 14:40, Nico Kadel-Garcia wrote:
> > Why would you want to move a Subversion server to a Windows system?
>
>
> Because that is what poster said they were migrating from. In existing
> deployments keeping the current authentication, logging and
> administration experience is probably more important than tweaks. So
> let's assume that this is on purpose.
From a considerable amount of painful experience with multiple
platforms, I suggest that the Windows backups and scripting would be
better discarded and re-implemented for the Linux based environment.
Many of them may require no tweaking, depending on the Windows server
environment. System stability and security are likelier to be much
better, as is system performance. Been there, done that, have the scar
tissue.
> > Definitely activate an svnsync to allow the new service to run in
> > parallel for a while, and to avoid any split-brain issues.
>
> Only if they cannot deal with a short migration read-only or down time.
I've made that "this will be only for a moment" prediction before.
I'll leave out the rude metaphors, but the claim is usually about as
reliable as a debtor saying "the check is in the mail". Especially for
a bulky server, with bulky commits the "out of service" time can tke
hours. Never schedule a system upgrade to occur with backup and
transfer in a tight time window if you can avoid it gracefully, and
"svnsync" allows pre-synchronization with a top-up of the last few
commots at switchover time. It's normally much, much cleaner,
especially with repos that have bulky binaries among old commits.
>
> Andreas
>
Re: Moving the entire SVN instance to a newer Windows server
Posted by Andreas Stieger <An...@gmx.de>.
On 5/22/22 14:40, Nico Kadel-Garcia wrote:
> Why would you want to move a Subversion server to a Windows system?
Because that is what poster said they were migrating from. In existing
deployments keeping the current authentication, logging and
administration experience is probably more important than tweaks. So
let's assume that this is on purpose.
> Definitely activate an svnsync to allow the new service to run in
> parallel for a while, and to avoid any split-brain issues.
Only if they cannot deal with a short migration read-only or down time.
Andreas
Re: Moving the entire SVN instance to a newer Windows server
Posted by Andreas Stieger <An...@gmx.de>.
Hi,
> If you have not used any of the advanced features in VisualSVN [...]
FWIF... The free VistualSVN version can* be set up to do full write-through proxying and async replication. It ships all the modules. (* last confirmed in ~2015)
Andreas
Re: Moving the entire SVN instance to a newer Windows server
Posted by Daniel Sahlberg <da...@gmail.com>.
Den sön 22 maj 2022 kl 17:59 skrev Bo Berglund <bo...@gmail.com>:
[...]
> So the relevant question for him is what kind of server they are running...
> If it is VisualSVN then they should go to that maintainer and ask for help.
>
>
> >There are real performance tuning issues for either httpd or svn+ssh
> >based access which are more easily handled in a Linux or UNIX
> >environment, and high reliability and backup setups far more difficult
> >to resolve in a Windows environment.
> >
> >Definitely activate an svnsync to allow the new service to run in
> >parallel for a while, and to avoid any split-brain issues.
>
>
> I have a similar problem where I have installed VisualSVN back in 2017 on a
> Windows 2016 Server and now I face problems keeping it updated.
>
> It is still on VisualSVN 3.7.0 and since I am remote to the server by
> 8,500 km I
> do not really dare experimenting with the updates....
>
I would be more worried about doing Windows updates remote (even seen a
server not coming online after an update?) than updating VisualSVN.
The few updates I have done on VisualSVN have been seemless and, as you
said yourself previously, as long as you have a valid support contract, I'm
sure VisualSVN will be more than happy to help you resolve any problems.
> This server runs SVN version as follows:
> H:\>svn --version
> svn, version 1.9.7 (r1800392)
> compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601
>
> It is still working but should be upgaded, only I don't know how to do it
> safely.
>
>
> The server is svn synced nightly over the Internet to a server I host in my
> premises, which is an Ubuntu Server 20.04.4 LTS and this runs:
> ~$ svn --version
> svn, version 1.13.0 (r1867053)
> compiled Apr 8 2022, 09:43:33 on x86_64-pc-linux-gnu
>
> On Linux the subversion upgrade is seamless with the apt program used to
> update/upgrade the whoile computer.
>
> So the OP (and myself) really need to create a Linux server to host the
> Subversion service going forward...
>
> What would be the proper way to migrate to a Linux based server and
> keeping the
> repository structure the same and allow user seamless access to these?
>
If you have not used any of the advanced features in VisualSVN (ie, only
using regular FSFS repositories and only Subversion authentication) you
should be able to follow the same advise already given in the thread: Stop
the service, copy the repository folders to the new server, configure the
new server to use the existing authn/authz files, point the existing DNS
names to the new server. As already pointed out you should check for any
dependencies in existing hook scripts (in particular, if you have any
binary hook scripts or using BATCH language).
Kind regards,
Daniel
Re: Moving the entire SVN instance to a newer Windows server
Posted by Bo Berglund <bo...@gmail.com>.
On Sun, 22 May 2022 08:40:55 -0400, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>On Sun, May 22, 2022 at 4:24 AM Andreas Stieger <An...@gmx.de> wrote:
>>
>> Hi,
>>
>> On 5/18/22 16:54, Mark Phippard wrote:
>> > If you can use the same DNS hostname for the new server there will be
>> > no impact on your clients
>>
>>
>> Except for possibly a change server-side certificate which may have
>> changed (and not properly verified before). Can be addressed with
>> testing, and it helps to use a service name instead of a host name.
>>
>> If you are looking to make this seamless, you can set up replication and
>> write-through proxying as you move the configuration and scripts first.
>
>Why would you want to move a Subversion server to a Windows system?
I think that he said:
>>>We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server.
So the relevant question for him is what kind of server they are running...
If it is VisualSVN then they should go to that maintainer and ask for help.
>There are real performance tuning issues for either httpd or svn+ssh
>based access which are more easily handled in a Linux or UNIX
>environment, and high reliability and backup setups far more difficult
>to resolve in a Windows environment.
>
>Definitely activate an svnsync to allow the new service to run in
>parallel for a while, and to avoid any split-brain issues.
I have a similar problem where I have installed VisualSVN back in 2017 on a
Windows 2016 Server and now I face problems keeping it updated.
It is still on VisualSVN 3.7.0 and since I am remote to the server by 8,500 km I
do not really dare experimenting with the updates....
This server runs SVN version as follows:
H:\>svn --version
svn, version 1.9.7 (r1800392)
compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601
It is still working but should be upgaded, only I don't know how to do it
safely.
The server is svn synced nightly over the Internet to a server I host in my
premises, which is an Ubuntu Server 20.04.4 LTS and this runs:
~$ svn --version
svn, version 1.13.0 (r1867053)
compiled Apr 8 2022, 09:43:33 on x86_64-pc-linux-gnu
On Linux the subversion upgrade is seamless with the apt program used to
update/upgrade the whoile computer.
So the OP (and myself) really need to create a Linux server to host the
Subversion service going forward...
What would be the proper way to migrate to a Linux based server and keeping the
repository structure the same and allow user seamless access to these?
--
Bo Berglund
Developer in Sweden
Re: Moving the entire SVN instance to a newer Windows server
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, May 22, 2022 at 4:24 AM Andreas Stieger <An...@gmx.de> wrote:
>
> Hi,
>
> On 5/18/22 16:54, Mark Phippard wrote:
> > If you can use the same DNS hostname for the new server there will be
> > no impact on your clients
>
>
> Except for possibly a change server-side certificate which may have
> changed (and not properly verified before). Can be addressed with
> testing, and it helps to use a service name instead of a host name.
>
> If you are looking to make this seamless, you can set up replication and
> write-through proxying as you move the configuration and scripts first.
Why would you want to move a Subversion server to a Windows system?
There are real performance tuning issues for either httpd or svn+ssh
based access which are more easily handled in a Linux or UNIX
environment, and high reliability and backup setups far more difficult
to resolve in a Windows environment.
Definitely activate an svnsync to allow the new service to run in
parallel for a while, and to avoid any split-brain issues.
Re: Moving the entire SVN instance to a newer Windows server
Posted by Andreas Stieger <An...@gmx.de>.
Hi,
On 5/18/22 16:54, Mark Phippard wrote:
> If you can use the same DNS hostname for the new server there will be
> no impact on your clients
Except for possibly a change server-side certificate which may have
changed (and not properly verified before). Can be addressed with
testing, and it helps to use a service name instead of a host name.
If you are looking to make this seamless, you can set up replication and
write-through proxying as you move the configuration and scripts first.
Andreas
Re: Moving the entire SVN instance to a newer Windows server
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 18, 2022 at 9:46 AM Morin, Michael <Mi...@maine.gov> wrote:
>
> We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server. Is there a simpler way to do this other than moving each repository one by one? I have over 170 repositories that I need to migrate to the new server. Can the entire SVN instance be backed up and restored….or copied over by some similar method?
Build the new server, install SVN, make sure it is working and
configured the way you want, then just stop both servers, copy the
entire repositories folder over to the new server and start it up.
If you can use the same DNS hostname for the new server there will be
no impact on your clients but if you change the name they will need to
use svn relocate to change the URL.
Only other thing to look out for is hook scripts that may exist in
your repositories and any dependencies those scripts rely on that
needs to be installed on the server.
Mark