Re: Moving the entire SVN instance to a newer Windows server
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
On Sun, May 22, 2022 at 4:24 AM Andreas Stieger 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
On Sun, 22 May 2022 08:40:55 -0400, Nico Kadel-Garcia wrote: >On Sun, May 22, 2022 at 4:24 AM Andreas Stieger 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
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
Den sön 22 maj 2022 kl 14:41 skrev Nico Kadel-Garcia : > On Sun, May 22, 2022 at 4:24 AM Andreas Stieger > 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
Den sön 22 maj 2022 kl 17:59 skrev Bo Berglund : [...] > 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
On Sun, May 22, 2022 at 12:02 PM Andreas Stieger 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 >
