You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by PR <rp...@gmail.com> on 2011/09/21 06:28:00 UTC
subversion upgrade from 1.4.6 to 1.7
Hello,
I have a question for the Subversion guru's out there.
we have a huge subversion installation with over 500 repositories in a
cluster environment currently on Subversion version 1.4.6 hosted on a redhat
as5 server.
I am planning to migrate this to Subversion 1.7.
I was reading thru the Subversion site and it seems like as simple as
1/ Build a new version of Apache and Subversion and all related modules.
2/ Bring the current installation down ..
3/ Push the new environment with the new apache server and subversion 1.7
server binary in path and bring up the apache server and the upgrade is
completed. (of course client side push to all the dev desktops with
subversion 1.7 will also be done simultaneously.)
is it really that simple?
I had read about previous upgrades to 1.6 (from 1.4.x or 1.5 ) and that the
dump and load was mandatory ...
I did try a quick repo tar and bring up in the new 1.7 rc3 subversion server
environment, access with file protocol and a local checkout and verified all
the subversion magic in place with the top level .svn, log with diff option,
the amazing checkout speeds and hence am really excited with the prospect of
quick move.
The only fact that left me a bit puzzled was that the repository format
still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3
with no error reported, ...
or I am missing something..?
Thanks in advance for your time.
Regards,
raj ..
PS:
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag PR,
am Mittwoch, 21. September 2011 um 06:28 schrieben Sie:
> The only fact that left me a bit puzzled was that the repository format
> still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3
> with no error reported, ...
This is because svnadmin verify doesn't change anything and only
replacing the binaries won't either upgrade your repositories.
Upgrading them is a separate process, where you have to options:
svnadmin upgrade will just upgrade the repositories to the most
current version your binaries are capable of, but only with doing the
most minimal work needed, therefore you won't benefit of the new
improvements with the old versions. svnadmin dump & load will upgrade
you repositories with improvements for all your old versions, for
example less occupied space due to enabled rep-sharing. svnadmin
upgrade is pretty fast, svnadmin dump & load won't be in most cases,
of course depending on your repository sizes.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Giulio Troccoli <gi...@mediatelgroup.co.uk>.
On 29/09/11 05:33, Rajesh wrote:
> On Wed, Sep 21, 2011 at 5:59 AM, Daniel Shahaf<d....@daniel.shahaf.name> wrote:
>> Hyrum K Wright wrote on Wed, Sep 21, 2011 at 05:44:33 -0500:
>>> 2011/9/21 Ulrich Eckhardt<ul...@dominolaser.com>:
>>>> Am 21.09.2011 11:00, schrieb Hyrum K Wright:
>>>> [repository upgrade]
>>>>> Since you are moving from 1.4 to 1.7, however, you may want to run
>>>>> 'svnadmin
>>>>> upgrade' on the new repositories, to enable new features available
>>>>> since 1.4.
>>>> Wait: I was under the impression that this enabled new features _as far as
>>>> possible_, but that some extensive internal changes (sharding? reverse
>>>> deltas? something?) actually required a dump/load cycle to make full use of,
>>>> or am I mistaken?
>>> You're right: sharding may require a load to enable (though I seem to
>>> recall a script somewhere would would do it to a live repo).
>>>
>>> Things like packing can be enabled with a simple upgrade of the repository.
>>>
>> Except that sharding is a prerequisite to packing.
>>
>
> wanted to thank each and every one for their suggestions..
> here is what i did.
> 1/ setup a new box with svn 1.7 rc3
> 2/ svnsync from main repo via a small script .. so all sync continues
> on a cron schedule
> 3/ I have about 500 repos and 200G data so will take a month to sync ..
> i observed that the packing is happening at the default 1000 rev into
> its own dir and i decided to leave it at that .
> 4/ will do a dns flip and bring the 1.7 up and running.
> 5/ remove the 0 th property so no one can accidentally sync from the
> previous location.
> 6/ make this new repo the master .. setup some other repository
> browsing tools on the old location.
> Thanks again for your time .. much appreciated help from each one of the folks.
> Regards,
> Raj
Don't forget to copy over your hooks as they are not copied by svnsync.
Also make sure to set the new repositories' UUIDs as the old ones or you
will have to do a switch --relocate on all your WCs
Giulio
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Rajesh <ra...@gmail.com>.
On Wed, Sep 21, 2011 at 5:59 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Hyrum K Wright wrote on Wed, Sep 21, 2011 at 05:44:33 -0500:
>> 2011/9/21 Ulrich Eckhardt <ul...@dominolaser.com>:
>> > Am 21.09.2011 11:00, schrieb Hyrum K Wright:
>> > [repository upgrade]
>> >>
>> >> Since you are moving from 1.4 to 1.7, however, you may want to run
>> >> 'svnadmin
>> >> upgrade' on the new repositories, to enable new features available
>> >> since 1.4.
>> >
>> > Wait: I was under the impression that this enabled new features _as far as
>> > possible_, but that some extensive internal changes (sharding? reverse
>> > deltas? something?) actually required a dump/load cycle to make full use of,
>> > or am I mistaken?
>>
>> You're right: sharding may require a load to enable (though I seem to
>> recall a script somewhere would would do it to a live repo).
>>
>> Things like packing can be enabled with a simple upgrade of the repository.
>>
>
> Except that sharding is a prerequisite to packing.
>
wanted to thank each and every one for their suggestions..
here is what i did.
1/ setup a new box with svn 1.7 rc3
2/ svnsync from main repo via a small script .. so all sync continues
on a cron schedule
3/ I have about 500 repos and 200G data so will take a month to sync ..
i observed that the packing is happening at the default 1000 rev into
its own dir and i decided to leave it at that .
4/ will do a dns flip and bring the 1.7 up and running.
5/ remove the 0 th property so no one can accidentally sync from the
previous location.
6/ make this new repo the master .. setup some other repository
browsing tools on the old location.
Thanks again for your time .. much appreciated help from each one of the folks.
Regards,
Raj
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K Wright wrote on Wed, Sep 21, 2011 at 05:44:33 -0500:
> 2011/9/21 Ulrich Eckhardt <ul...@dominolaser.com>:
> > Am 21.09.2011 11:00, schrieb Hyrum K Wright:
> > [repository upgrade]
> >>
> >> Since you are moving from 1.4 to 1.7, however, you may want to run
> >> 'svnadmin
> >> upgrade' on the new repositories, to enable new features available
> >> since 1.4.
> >
> > Wait: I was under the impression that this enabled new features _as far as
> > possible_, but that some extensive internal changes (sharding? reverse
> > deltas? something?) actually required a dump/load cycle to make full use of,
> > or am I mistaken?
>
> You're right: sharding may require a load to enable (though I seem to
> recall a script somewhere would would do it to a live repo).
>
> Things like packing can be enabled with a simple upgrade of the repository.
>
Except that sharding is a prerequisite to packing.
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Hyrum K Wright <hy...@wandisco.com>.
2011/9/21 Ulrich Eckhardt <ul...@dominolaser.com>:
> Am 21.09.2011 11:00, schrieb Hyrum K Wright:
> [repository upgrade]
>>
>> Since you are moving from 1.4 to 1.7, however, you may want to run
>> 'svnadmin
>> upgrade' on the new repositories, to enable new features available
>> since 1.4.
>
> Wait: I was under the impression that this enabled new features _as far as
> possible_, but that some extensive internal changes (sharding? reverse
> deltas? something?) actually required a dump/load cycle to make full use of,
> or am I mistaken?
You're right: sharding may require a load to enable (though I seem to
recall a script somewhere would would do it to a live repo).
Things like packing can be enabled with a simple upgrade of the repository.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 21.09.2011 11:00, schrieb Hyrum K Wright:
[repository upgrade]
> Since you are moving from 1.4 to 1.7, however, you may want to run 'svnadmin
> upgrade' on the new repositories, to enable new features available
> since 1.4.
Wait: I was under the impression that this enabled new features _as far
as possible_, but that some extensive internal changes (sharding?
reverse deltas? something?) actually required a dump/load cycle to make
full use of, or am I mistaken?
Greetings!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Sep 21, 2011 at 2:36 AM, Ulrich Eckhardt
<ul...@dominolaser.com> wrote:
> Am 21.09.2011 06:28, schrieb PR:
>>
>> of course client side push to all the dev desktops with
>> subversion 1.7 will also be done simultaneously.
>
> This is not necessary, you can switch one client first, then other clients
> and finally switch the server. BTW: 1.7 is still not yet released, though
> it's really really close now, AFAICT.
>
>
>> is it really that simple?
>
> Yes, your approach is correct. I'd suggest testing that though, e.g. by
> using a separate system.
>
>
>> I had read about previous upgrades to 1.6 (from 1.4.x or 1.5 ) and that
>> the
>> dump and load was mandatory ...
>
> This is not mandatory, but the organisation of the repository changed to the
> better in recent versions, so a dump and reload is strongly suggested. In
> particular things like merge tracking have improved, IIRC.
A dump / load when upgrading Subversion has never been mandatory.
There may have been added benefits from doing so, but old repositories
will continue to function under new versions of Subversion. When
upgrading Subversion installations, I'd encourage you to read the
relevant release notes:
http://subversion.apache.org/docs/release-notes/
>> I did try a quick repo tar and bring up in the new 1.7 rc3 subversion
>> server
>> environment, access with file protocol and a local checkout and verified
>> all
>> the subversion magic in place with the top level .svn, log with diff
>> option,
>> the amazing checkout speeds and hence am really excited with the prospect
>> of
>> quick move.
>>
>> The only fact that left me a bit puzzled was that the repository format
>> still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3
>> with no error reported, ...
This is no server-side format changes between 1.6 and 1.7. Since you
are moving from 1.4 to 1.7, however, you may want to run 'svnadmin
upgrade' on the new repositories, to enable new features available
since 1.4. This should all be covered in the relevant release notes.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: subversion upgrade from 1.4.6 to 1.7
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 21.09.2011 06:28, schrieb PR:
> of course client side push to all the dev desktops with
> subversion 1.7 will also be done simultaneously.
This is not necessary, you can switch one client first, then other
clients and finally switch the server. BTW: 1.7 is still not yet
released, though it's really really close now, AFAICT.
> is it really that simple?
Yes, your approach is correct. I'd suggest testing that though, e.g. by
using a separate system.
> I had read about previous upgrades to 1.6 (from 1.4.x or 1.5 ) and that the
> dump and load was mandatory ...
This is not mandatory, but the organisation of the repository changed to
the better in recent versions, so a dump and reload is strongly
suggested. In particular things like merge tracking have improved, IIRC.
> I did try a quick repo tar and bring up in the new 1.7 rc3 subversion server
> environment, access with file protocol and a local checkout and verified all
> the subversion magic in place with the top level .svn, log with diff option,
> the amazing checkout speeds and hence am really excited with the prospect of
> quick move.
>
> The only fact that left me a bit puzzled was that the repository format
> still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3
> with no error reported, ...
Well, an "svnadmin verify" hopefully doesn't modify the repository.
Good luck!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************