[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Upgrade from 1.1.3 to 1.1.4

From: John Szakmeister <john_at_szakmeister.net>
Date: 2005-04-08 11:31:22 CEST

On Thursday 07 April 2005 23:26, Ed Hillmann wrote:
> Hi all. I've got SVN 1.1.3 installed on a Linux box
> which hosts a Repository. I see that 1.1.4 has been
> released. I read the topic in the SVN book about
> migrating a repository
> (http://svnbook.red-bean.com/en/1.0/ch05s03.html#svn-ch-5-sect-3.5),
> and I was curious if there were "changes made to the
> back-end database schema cause Subversion to be
> incompatible with previous versions of the
> repository". In other words, do I have to export out
> my repository before I upgrade my SVN installation.

No. Right now, our compatibility rules state that a dump/load would only
be required between major versions of the tools. IOW, if you were
upgrading from 1.x.x to 2.y.y, then you would need to do a dump/load.

> A further question: Are DB changes the only reason to
> migrate a repository? My repository doesn't use
> Berkeley. It uses fsfs. Is this even an issue for
> me?

I'm not sure I understand your question. I think you're trying to ask if
upgrades only involves DB changes. The answer to that is an emphatic
'No'. There are many reasons to upgrade. Bugs get fixed, security holes
get closed, performance enhancements, and of course, new functionality
(such as locking in 1.2).

FWIW, just because you use FSFS, it doesn't mean that you're going to
avoid a dump/load cycle. There may very well be incompatible schema
changes from 1.x to 2.x. But that's a little ways off, so you're fine
for the time being. :-)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 8 11:41:07 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.