Hi Nico, Thanks a million for your detailed reply, I will be testing svnmirror solution then if it worked as expected, will use it.
Thanks & BRs Mai Saleh IT Global Technologies & Infrastructure Software Tools Engineer [cid:image001.png@01D33224.67E32FF0] From: Nico Kadel-Garcia [mailto:nka...@gmail.com] Sent: Wednesday, September 20, 2017 3:08 PM To: Saleh, Mai <mai_sa...@mentor.com> Cc: corneil.duples...@gmail.com; users@subversion.apache.org Subject: Re: Subversion Server Replacement Query On Wed, Sep 20, 2017 at 8:27 AM, Saleh, Mai <mai_sa...@mentor.com<mailto:mai_sa...@mentor.com>> wrote: I will really appreciate, if you could help in “Can I know please what will be the risk to use rsync as it worked in our tests.” Why do we have to take dump and load, that will take week due to number and size, if you can clarify why not just take a copy of current repositories to new shared area via rsync, will be great ☺ Storing the Subversion server repository on NFS is a separate issue. If your repository is oversized, it can be a real temptation to put it on a separate storage server, but it carries its own risks and can leave your repository corrupted, accidentally, as two write operations occur close to each other but are not immediately *visiable* to another process checking for Subversion records. This has nothing to do with your problem you asked about, it's just good advice for your Subversion servers. If you can lock the current server and rsync over, then upgrade in place, *maybe* that will work. It's also likely to work better switching one repo, or small sets of repos at a time, if you have many, many repositories. Bu if it's one huge repo, it's also a chance to split it to more manageable pieces. You say that dump and load "will take a week". That hints that it's too damn big and it's time to trim. Dump and load gives you an opportunity to clear obsolete and bulky content, and switch servers to a new, slimmer, possibly much more responsive service. Workers would definitely have to check out new working copies. But that's typically a good idea anyway, after a major back-end shift, because subtle changes in handling of things like EOL in comments can create adventures in the migration. The "svnmirror" approach is commonly used for these problems. Start a mirror on your Subversion 1.9 server, allowing it to catch up with the production Subversion. That can run for the days or week, in the background, and should automatically give you a working Subversion 1.9 server. *Then* turn off access to the old server. especially write access. *Then* switch your DNS or web services to point to the new server. *Then* make damn sure that old server is disabled, preferably with the entire Subversion repo set aside. *Then* turn on write to the new server, ideally with a new URL to make clear that this is a *new* service, and to make people think before they just continue writing to the old service. There are enough feature changes between 1.6 and 1.9 to justify this, I think. I'd recommend using a new URL for access to the old server, and leaving the old server disabled. *Maybe* leave it with a separate URL for read-only access, just in case the new server fails and you need access to an obsolete repo. Thanks & BRs Mai Saleh IT Global Technologies & Infrastructure Software Tools Engineer [cid:image001.png@01D33224.67E32FF0] From: corneil.duples...@gmail.com<mailto:corneil.duples...@gmail.com> [mailto:corneil.duples...@gmail.com<mailto:corneil.duples...@gmail.com>] Sent: Wednesday, September 20, 2017 2:15 PM To: Saleh, Mai <mai_sa...@mentor.com<mailto:mai_sa...@mentor.com>> Cc: users@subversion.apache.org<mailto:users@subversion.apache.org> Subject: Re: Subversion Server Replacement Query The user's working copies should be fine. In my experience older clients are fine with newer servers and newer clients are fine with older workspace formats. Corneil du Plessis about.me/corneil<http://about.me/corneil> On 20 September 2017 at 12:29, Saleh, Mai <mai_sa...@mentor.com<mailto:mai_sa...@mentor.com>> wrote: Hi Corneil, Thanks a million for your reply. It has been years since we use NFS, so no worries about that. Can I know please what will be the risk to use rsync as it worked in our tests. Do users need to create a new working copies after moving to new version? Thanks & BRs Mai Saleh IT Global Technologies & Infrastructure Software Tools Engineer [cid:image001.png@01D33224.67E32FF0] From: corneil.duples...@gmail.com<mailto:corneil.duples...@gmail.com> [mailto:corneil.duples...@gmail.com<mailto:corneil.duples...@gmail.com>] Sent: Wednesday, September 20, 2017 12:23 PM To: Saleh, Mai <mai_sa...@mentor.com<mailto:mai_sa...@mentor.com>> Cc: users@subversion.apache.org<mailto:users@subversion.apache.org> Subject: Re: Subversion Server Replacement Query In short: Don't host on NFS or any remote filesystem. It is better to dump and import, you can do the dump with old or new version but will only benefit from all new features and stability with the repository in the newer version. Corneil du Plessis about.me/corneil<http://about.me/corneil> On 20 September 2017 at 11:06, Saleh, Mai <mai_sa...@mentor.com<mailto:mai_sa...@mentor.com>> wrote: Hi Subversion Support, Please advise as we need to move subversion from old server with OS RH5U3 to RH7U3, all of our repositories are hosted on NFS share. SVN version on old server is 1.6.x and new server has version 1.9.7. Plan is to rsync old shared area hosting repositories to new shared area and copy configuration files to the same path on new server. So repositories and configuration files will be in exact paths. Then we will rename new server with original server name. Initial test succeeded, but we need to know is there anything that we need to take care of, do we have to use dump and load as that will take lots of time, due to history and size of repositories. Do users need to create a new working copies? Thanks & BRs Mai Saleh IT Global Technologies & Infrastructure Software Tools Engineer [cid:image001.png@01D33224.67E32FF0]
