On 05/09/13 15:46, Maureen Barger wrote:
> 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.troccoli_at_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
Bear in mind this was about 4 years ago and I moved company so I don't
have my notes.
I actually started using svnsync for our DR, but then I realised it's an
excellent tool for upgrading too.
What I did was roughly something like:
- get the UUID for the old repo
- svnadmin create
- set up appropriate hooks - you need to do something with the hooks,
the book should be able to tell you exactly what
- svnadmin setuuid
- svnsync init
- svnsync sync - this should be done few times because the first time
it will take a long time and by the time it finished there were quite a
few new revisions. Basically you need to reach a point when the next
svnsycn sync will take very little
- stop commits to the old repo - use the start-commit hook
- svnsync sync - one final sync
- remove a couple of svn properties on revision 0 on the new repo - I
don't remember what they are called, but they are used by svnsync to
keep track of what it's done.
- remove all hooks for the new repo and copy over all hooks from the old
one - this was a bit tricky for me as one hook stopped working because
of the new environment, so take care (of course if you test everything
before doing the real thing you will be fine when you do it for real)
- change the dns so the the repo's URL points to the new server
- done - you may want to tell the users. Becuase the two repos ahve the
same UUID and the URL hasn't change the users don't have to do any svn
switch at all.
Don't forget to take care of authentication and authorisation. I think I
had only one user allowed to write to the new repo, which was the
special user I used for svnsync (with the --sync-username). After the
last svnsync sync I set up all correct authentication and authorisation.
Sorry for beign a bit too sketchy, but as I said it was about 4 years
ago and I don't have any notes.
Good luck
Giulio
Received on 2013-09-05 17:18:45 CEST