On Friday 25 Jun 2010, abhinav.chandra_at_rbs.com wrote:
> Hi,
>
> We are currently using Subversion 1.5.2 and want to upgrade to Subversion
> 1.6.6.
>
> Upon going through subversion documentation, we found that there can be two
> ways of doing this:
>
> 1. Installing a new Subversion 1.6.6 instance and simply upgrading all the
> repositories via the svnadmin upgrade command. 2. Creating dumps of each of
> the repositories from Subversion 1.5.2 instance and loading them into the
> newly installed Subversion 1.6.6 instance.
>
> Can anyone please guide us which of these two options should we go for ?
>
> The help text for 'svnadmin upgrade' command says that it "performs only
> the minimum amount of work needed to accomplish this while still
> maintaining the integrity of the repository. It does not guarantee the most
> optimized repository state as a dump and subsequent load would":
>
> $/> svnadmin help upgrade
> upgrade: usage: svnadmin upgrade REPOS_PATH
>
> Upgrade the repository located at REPOS_PATH to the latest supported
> schema version.
>
> This functionality is provided as a convenience for repository
> administrators who wish to make use of new Subversion functionality
> without having to undertake a potentially costly full repository dump
> and load operation. As such, the upgrade performs only the minimum
> amount of work needed to accomplish this while still maintaining the
> integrity of the repository. It does not guarantee the most optimized
> repository state as a dump and subsequent load would.
>
>
> But, following excerpt from Subversion Documentation
> (http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.repos
>admin.maint.migrate) says that there is no requirement of doing dump and
> reload between versions 1.5.x to 1.6.x :
>
> "As Subversion matured, there were times when changes made to the backend
> database schema caused compatibility issues with previous versions of the
> repository, so users had to dump their repository data using the previous
> version of Subversion and load it into a freshly created repository with
> the new version of Subversion. Now, these types of schema changes haven't
> occurred since Subversion's 1.0 release, and the Subversion developers
> promise not to force users to dump and load their repositories when
> upgrading between minor versions (such as from 1.3 to 1.4) of Subversion."
>
> Also, the release note for Subversion 1.6.x
> (http://subversion.apache.org/docs/release-notes/1.6.html) says the same:
>
> "There is no need to dump and reload your repositories. Subversion 1.6 can
> read repositories created by earlier versions. To upgrade an existing
> installation, just install the newest libraries and binaries on top of the
> older ones. Working Copy Upgrades
> WARNING: if a Subversion 1.6 client encounters a pre-1.6 working copy, it
> will automatically upgrade the working copy format as soon as it touches
> it, making it unreadable by older Subversion clients. If you are using
> several versions of Subversion on your machine, be careful about which
> version you use in which working copy, to avoid accidentally upgrading a
> working copy. (But note that this "auto upgrade" behavior does not occur
> with the repositories, only working copies.) If you accidentally upgrade a
> 1.5 working copy to 1.6, and wish to downgrade back to 1.5, use the
> change-svn-wc-format.py script. See this FAQ entry for details, and run the
> script with the --help option for usage instructions. Repository Upgrades
> The Subversion 1.6 server works with 1.5 and older repositories, and it
> will not upgrade such repositories to 1.6 unless specifically requested to
> via the svnadmin upgrade command. This means that some of the new 1.6
> features will not become available simply by upgrading your server: you
> will also have to upgrade your repositories. (We decided not to
> auto-upgrade repositories because we didn't want 1.6 to silently make
> repositories unusable by 1.5 - that step should be a conscious decision on
> the part of the repository admin.) "
>
>
> Please provide your suggestion whether we should go for dump and load of
> all repositories (as in option 2) or option 1 would be as good ?
>
> Thanks and Regards,
> Abhinav Chandra
> RBS Global Banking & Markets
> Office: +91 124 479 1752
I've always gone for the dump and load approach for the following reasons:
1. It's another backup.
2. Creating and loading it verifies all your revisions in the existing
repository are valid. The dump backup from 1 can be used in case a revision
does get corrupted later.
3. It's practice for recovering a repository.
4. Reverting back to the previous version for whatever reason is simple and
very quick if you keep the old repositories in a parallel directory but
obviously changes made in the new one will not be reflected in the old.
5. Tweaks to the repository can be made at this time such as permanently
removing items.
6. It does take some time but the approach also allows for testing the new
repository and settings before allowing general access. It can also be done
whilst the existing repository is still running by using incremental dumps.
Regardless of the server version your clients working copy can remain on their
current version and upgrade when they are comfortable to do so unless they
need particular features that requires both server and client to be 1.6.
I'm curious about your choice of version as 1.6.12 is the current stable
release. Why choose 1.6.6?
Campbell
__________________________________________________________________________________
Sword Ciboodle is the trading name of ciboodle Limited (a company
registered in Scotland with registered number SC143434 and whose
registered office is at India of Inchinnan, Renfrewshire, UK,
PA4 9LH) which is part of the Sword Group of companies.
This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you,
please inform us and then delete it. If you are not the intended
recipient(s), the use, disclosure, copying or distribution of any
information contained within this email is prohibited. Messages to
and from us may be monitored. If the content is not about the
business of the Sword Group then the message is neither from nor
sanctioned by us.
Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__________________________________________________________________________________
Received on 2010-06-25 11:10:41 CEST