RE: Moving the entire SVN instance to a newer Windows server
-Original Message- From: Bo Berglund Sent: Monday, May 23, 2022 8:09 AM To: users@subversion.apache.org Subject: Re: Moving the entire SVN instance to a newer Windows server EXTERNAL: This email originated from outside of the State of Maine Mail System. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, 23 May 2022 11:03:32 +, "Morin, Michael" wrote: >>On Mon, May 23, 2022 at 6:16 AM Morin, Michael >>wrote: >>> >>> In my case, I have no choice in the matter of what server and OS to move >>> to. We don’t use VisualSVN. >>>We just use Tortoise with Subversion. When we last >did a migration >>>from one Windows server to another, it was a tedious process of >>>contacting the users of the repository, asking them if the repo >>>should be migrated or archived, setting a date for the migration, >>>telling the users to make any outstanding commits, locking down the >>>repository, migrating the >repository, informing users of the new URL of the >>>repository, and asking the users to confirm their ability to access the repo >>>and verifying everything >works as expected. >>>This was done for each repository. This process took us about 4 ½ >>>months. I’d like to avoid taking that long this time around. >> >>*Ouch*. Been there, done that. I'm assuming that each repo is, indeed, >>an entirely distinct Subversion repo rather than all being distributed under >>one >master repo? That makes migration much, much safer. >> >Yes, each repository is a distinct Subversion repository. We have about >300 Subversion users located in different departments and 171 repositories. > Just to clarify for my understanding: Are you saying that the users are accessing the repositories via file sharing in Windows using Tortoise-Svn? I.e. do they point the client (Tortoise-SVN) to a drive letter location where they operate on the repository? In that case you do not even have a *server* running so migrating the *server* is a non-issue. And the whole setup is pretty vulnerable to rogue users with write permissions on the repository side... > The server is running two services: CollabNet Subversion Edge and CollabNet > Subversion Server. Users interact with the repositories by typing the URL of > the repository into Tortoise.
Re: Moving the entire SVN instance to a newer Windows server
On Mon, 23 May 2022 11:03:32 +, "Morin, Michael" wrote: >>On Mon, May 23, 2022 at 6:16 AM Morin, Michael >>wrote: >>> >>> In my case, I have no choice in the matter of what server and OS to move >>> to. We dont use VisualSVN. >>>We just use Tortoise with Subversion. When we last >did a migration from one >>>Windows server to another, >>>it was a tedious process of contacting the users of the repository, asking >>>them if the repo should be >>>migrated or archived, setting a date for the migration, telling the users to >>>make any outstanding commits, >>>locking down the repository, migrating the >repository, informing users of >>>the new URL of the repository, >>>and asking the users to confirm their ability to access the repo and >>>verifying everything >works as expected. >>>This was done for each repository. This process took us about 4 ½ months. >>>Id like to avoid taking that >>>long this time around. >> >>*Ouch*. Been there, done that. I'm assuming that each repo is, indeed, an >>entirely distinct Subversion >>repo rather than all being distributed under one >master repo? That makes >>migration much, much safer. >> >Yes, each repository is a distinct Subversion repository. We have about 300 >Subversion users located in >different departments and 171 repositories. > Just to clarify for my understanding: Are you saying that the users are accessing the repositories via file sharing in Windows using Tortoise-Svn? I.e. do they point the client (Tortoise-SVN) to a drive letter location where they operate on the repository? In that case you do not even have a *server* running so migrating the *server* is a non-issue. And the whole setup is pretty vulnerable to rogue users with write permissions on the repository side... PS: Please do not top-post, it makes it so much harder to follow the discussion. DS -- Bo Berglund Developer in Sweden
Re: Moving the entire SVN instance to a newer Windows server
Hi, > We just use Tortoise with Subversion. You mean just plain file:// access? (no mod_dav_svn or svn)? Then there is not even a Subversion server involved. Is there any way you can re-use the hostname? Andreas
RE: Moving the entire SVN instance to a newer Windows server
Yes, each repository is a distinct Subversion repository. We have about 300 Subversion users located in different departments and 171 repositories. -Original Message- From: Nico Kadel-Garcia Sent: Monday, May 23, 2022 6:58 AM To: Morin, Michael Cc: users@subversion.apache.org Subject: Re: Moving the entire SVN instance to a newer Windows server EXTERNAL: This email originated from outside of the State of Maine Mail System. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, May 23, 2022 at 6:16 AM Morin, Michael wrote: > > In my case, I have no choice in the matter of what server and OS to move to. > We don’t use VisualSVN. We just use Tortoise with Subversion. When we last > did a migration from one Windows server to another, it was a tedious process > of contacting the users of the repository, asking them if the repo should be > migrated or archived, setting a date for the migration, telling the users to > make any outstanding commits, locking down the repository, migrating the > repository, informing users of the new URL of the repository, and asking the > users to confirm their ability to access the repo and verifying everything > works as expected. This was done for each repository. This process took us > about 4 ½ months. I’d like to avoid taking that long this time around. *Ouch*. Been there, done that. I'm assuming that each repo is, indeed, an entirely distinct Subversion repo rather than all being distributed under one master repo? That makes migration much, much safer. > 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
On Mon, May 23, 2022 at 6:16 AM Morin, Michael wrote: > > In my case, I have no choice in the matter of what server and OS to move to. > We don’t use VisualSVN. We just use Tortoise with Subversion. When we last > did a migration from one Windows server to another, it was a tedious process > of contacting the users of the repository, asking them if the repo should be > migrated or archived, setting a date for the migration, telling the users to > make any outstanding commits, locking down the repository, migrating the > repository, informing users of the new URL of the repository, and asking the > users to confirm their ability to access the repo and verifying everything > works as expected. This was done for each repository. This process took us > about 4 ½ months. I’d like to avoid taking that long this time around. *Ouch*. Been there, done that. I'm assuming that each repo is, indeed, an entirely distinct Subversion repo rather than all being distributed under one master repo? That makes migration much, much safer. > 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
In my case, I have no choice in the matter of what server and OS to move to. We don't use VisualSVN. We just use Tortoise with Subversion. When we last did a migration from one Windows server to another, it was a tedious process of contacting the users of the repository, asking them if the repo should be migrated or archived, setting a date for the migration, telling the users to make any outstanding commits, locking down the repository, migrating the repository, informing users of the new URL of the repository, and asking the users to confirm their ability to access the repo and verifying everything works as expected. This was done for each repository. This process took us about 4 ½ months. I'd like to avoid taking that long this time around. 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
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
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 >
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
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
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
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 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
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 Wed, May 18, 2022 at 9:46 AM Morin, Michael 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
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 restoredor copied over by some similar method? Mike Morin Senior Programmer Analyst MaineIT, Department of Administrative and Financial Services (207)592-6134
