Re: Planning a SVN upgrade
On Thu, Sep 5, 2013 at 10:46 AM, Maureen Barger mobar...@gmail.com wrote: That is a great idea, Giulio. How do you then make the mirrored repo writable? You don't make mirrors writable. You can make them read-only, and do pass-through for write operations to the main repository for low grade failover behavior, but mirrors are always, always, always at risk of split-brain problems for write operations *unless* you invest enormous sophistication in keeping them synced with the master, *or* unless you just inveest some cash up front in the more sophisticated commercial tools our friends and developers over at Wandisco provide their commercial grade Multi-Site setups. Doing manual switchovers of clients to an aalternative upstream mirrored site is awkward and painful enough that, for commercial use, I'd go to Multi-Site based tools in a heartbeat..
Re: Planning a SVN upgrade
That is a great idea, Giulio. How do you then make the mirrored repo writable? On Mon, Sep 2, 2013 at 4:47 AM, Giulio Troccoli giulio.trocc...@mediatelgroup.co.uk wrote: On 23/08/13 21:09, Maureen Barger wrote: Hi - I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. I do not foresee any changes I would need to make to Jenkins or Nexus. Has anyone made a jump this large before? Any comments about my upgrade plan? Thanks! Being a totally new server, may I suggest using svnsync instead of a dump/load cycle? It's very easy to set up, you can still use the old repositories while syncing and if you take care of using the same UUID on the new repository you might even be able to make the switch completely transparent to the clients. I did an upgrade about three years ago, I think from 1.4 to 1.6, and I used svnsync. It worked very well. I don't share others' concerns about not upgrading the repository (which will happen if you use svnsync). I don't see why now. Besides, using svnsync, you don't touch the old repositories at all so you still have the old format repos if you need them. Just my 2p
Re: Planning a SVN upgrade
On 23/08/13 21:09, Maureen Barger wrote: Hi - I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. I do not foresee any changes I would need to make to Jenkins or Nexus. Has anyone made a jump this large before? Any comments about my upgrade plan? Thanks! Being a totally new server, may I suggest using svnsync instead of a dump/load cycle? It's very easy to set up, you can still use the old repositories while syncing and if you take care of using the same UUID on the new repository you might even be able to make the switch completely transparent to the clients. I did an upgrade about three years ago, I think from 1.4 to 1.6, and I used svnsync. It worked very well. I don't share others' concerns about not upgrading the repository (which will happen if you use svnsync). I don't see why now. Besides, using svnsync, you don't touch the old repositories at all so you still have the old format repos if you need them. Just my 2p
RE: Planning a SVN upgrade
From: Mark Phippard Sent: Saturday, 24 August 2013 6:35 AM On Fri, Aug 23, 2013 at 4:09 PM, Maureen Barger wrote: I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. We have just upgraded our server from 1.2.3 to 1.8.1, including a move from Apache 2.0 to Apache2.2. It took me some time, but it was done as a bit of a background task. There were 74 BDB repositories that had to be dumped and loaded to FSFS format. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. If it were me, I would not upgrade the repositories. SVN 1.8 can just serve the old repositories. I would do the upgrade and only after I was using it for a while would I then consider to start doing a dump/load on the repositories. You could then do them one by one as desired. The main benefit in upgrading the repository is to use less disk space. I also would not upgrade existing repositories just for the sake of it. If there's a feature you feel would be useful that's only available with the 1.8 repo format, then I would do it, but ONLY for the active repos. The only reason I upgraded the BDB repositories was because I could no longer access them with the new server software. Even then, I left them in the 1.2 format in case we had to go back to the original server for some reason. If you're going to do an upgrade on the repositories, make sure you back them up first. Then the disk space issue becomes moot, because the backups take space as well. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. Yes, your clients can already be using 1.8 if they want to. There is no need to upgrade the client either before or after the server. Let the clients manage it. Only exception is if there are specific new features you want to implement across the board. If you do a lot of branching and merging, it would be a good idea for the people that do merge to all be using the same version. Likewise, there are other features that might be like this. I concur. (Of course, Mark has a lot more SVN experience and in-depth knowledge than I do.) Leave it to the individual to decide whether to upgrade. There are very few cases where the server and client software are incompatible between versions. Mind you, I did have to do our upgrade to the server because version 1.8.x of the client doesn't play nicely with version 1.2.x of the server, in terms of adding new files and displaying logs. That's how I came to join the mailing lists in the first place. I do not foresee any changes I would need to make to Jenkins or Nexus. Just the URL to access the repository will change. Even that doesn't have to change. We're using the same URLs. Has anyone made a jump this large before? Any comments about my upgrade plan? There is nothing unusual about this. People have jumped from 1.1 to 1.8. In my case, 1.2 to 1.8. By comparison, 1.5 to 1.8 should be easy. Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Planning a SVN upgrade
Hi - I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. I do not foresee any changes I would need to make to Jenkins or Nexus. Has anyone made a jump this large before? Any comments about my upgrade plan? Thanks!
