You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by James Ralston <qr...@andrew.cmu.edu> on 2011/02/28 19:37:46 UTC
can "svnadmin dump" tolerate read-only repository access?
Recently, Red Hat Enterprise Linux 5 updated its Subversion package
from 1.5.x to 1.6.11.
This exposed a *forwards* compatibility problem: the Subversion 1.6
hotcopy command fails on Subversion 1.5 repositories:
$ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $?
svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory
1
We tested if creating an empty db/fsfs.conf file will resolve this
issue, and it does. And this issue seems to have been fixed in 1.6.13.
But given that this very simple compatibility issue wasn't caught
until two bugfix releases later, we're concerned that there may be
other forwards compatibility issues that will bite us in the future.
Therefore, we've decided to dump and restore all of our Subversion
repositories, to bring them up to Subversion 1.6 db backends.
Question: if I "svnadmin dump" a repository, is it safe to allow
read-only access to the repository while the dump is in progress? Or
is it the case that permitting even read access could interfere with
the "svnadmin dump" operation?
I ask because it will take a non-trivial amount of time to perform
svnadmin dump/load operations on all of Subversion repositories. If
we can at least permit read-only access while this upgrade is in
progress, that will have much less of an impact on our users then it
we have to block all access during the upgrade...
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by David Chapman <dc...@acm.org>.
On 2/28/2011 11:00 AM, James Ralston wrote:
> On 2011-02-28 at 10:49-08 David Chapman<dc...@acm.org> wrote:
>> A "hot copy" by definition is one that will safely allow read-only
>> access while the backup is in progress.
> But I asked about "svnadmin dump", not "svnadmin hotcopy".
>
> Are you asserting that read-only repository access (in our case, via
> WebDAV via mod_dav_svn) will *not* perturb a running "svnadmin dump"
> operation?
>
>
Sorry, missed that detail.
Per the book:
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnadmin
"Note that *svnadmin dump* is reading revision trees from the repository
just like any other "reader" process would (e.g., *svn checkout*), so
it's safe to run this command at any time."
You may have to scroll down a bit to find this text.
I always do a hot copy first; since no one else can access the hot copy
I don't have to worry about "svnadmin dump" conflicts. Of course, my
repositories are still writable while I'm running my backups. The main
issue as I understand it is determining exactly which revision is the
"last" and not copying any data beyond that one. For you, hot copy plus
dump would take longer, which would be an issue for your developers.
But if you prevent commits (including revprop changes) during the
transition, you should be fine.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by James Ralston <qr...@andrew.cmu.edu>.
On 2011-02-28 at 10:49-08 David Chapman <dc...@acm.org> wrote:
> A "hot copy" by definition is one that will safely allow read-only
> access while the backup is in progress.
But I asked about "svnadmin dump", not "svnadmin hotcopy".
Are you asserting that read-only repository access (in our case, via
WebDAV via mod_dav_svn) will *not* perturb a running "svnadmin dump"
operation?
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by David Chapman <dc...@acm.org>.
On 2/28/2011 10:37 AM, James Ralston wrote:
> <snip>
> Question: if I "svnadmin dump" a repository, is it safe to allow
> read-only access to the repository while the dump is in progress? Or
> is it the case that permitting even read access could interfere with
> the "svnadmin dump" operation?
>
> I ask because it will take a non-trivial amount of time to perform
> svnadmin dump/load operations on all of Subversion repositories. If
> we can at least permit read-only access while this upgrade is in
> progress, that will have much less of an impact on our users then it
> we have to block all access during the upgrade...
>
A "hot copy" by definition is one that will safely allow read-only
access while the backup is in progress.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
'svnadmin dump' can work on live repositories, even if they're being
written to as it goes.
In general, ANY Subversion command can be run on live repositories.
It's rsync and friends that aren't promised to work on live
repositories.
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Mon, Feb 28, 2011 at 14:33:56 -0600:
> Isn't it correct, though, that any 1.y server or client should be able
> to access locally any repository created with 1.x if 1.x <= 1.y?
Yes, svn 1.y can read repositories created by 1.x for x<=y, as well as
repositories created by 1.z with an appropriate --pre-1.%d-compatible
flag.
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 28, 2011, at 14:29, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Mon, Feb 28, 2011 at 13:33:51 -0600:
>>
>> The Subversion team's promise is that any Subversion 1.x client will
>> be compatible with any Subversion 1.x server, and I would assume with
>> any Subversion 1.x repository. If bugs are introduced that break that
>> promise, I'm confident that those bugs would be fixed.
>
> Any 1.x and 1.y are compatible *over the wire*.
>
> If you want to access a repository locally (svnadmin) you might not be
> able to access a repository that had been upgraded/created by an
> svnadmin of a newer minor version.
Er, yes. I worded that wrong.
Isn't it correct, though, that any 1.y server or client should be able to access locally any repository created with 1.x if 1.x <= 1.y?
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Mon, Feb 28, 2011 at 13:33:51 -0600:
>
> On Feb 28, 2011, at 12:37, James Ralston wrote:
>
> > Recently, Red Hat Enterprise Linux 5 updated its Subversion package
> > from 1.5.x to 1.6.11.
> >
> > This exposed a *forwards* compatibility problem: the Subversion 1.6
> > hotcopy command fails on Subversion 1.5 repositories:
> >
> > $ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $?
> > svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory
> > 1
> >
> > We tested if creating an empty db/fsfs.conf file will resolve this
> > issue, and it does. And this issue seems to have been fixed in 1.6.13.
> >
> > But given that this very simple compatibility issue wasn't caught
> > until two bugfix releases later, we're concerned that there may be
> > other forwards compatibility issues that will bite us in the future.
>
> The Subversion team's promise is that any Subversion 1.x client will
> be compatible with any Subversion 1.x server, and I would assume with
> any Subversion 1.x repository. If bugs are introduced that break that
> promise, I'm confident that those bugs would be fixed.
>
Any 1.x and 1.y are compatible *over the wire*.
If you want to access a repository locally (svnadmin) you might not be
able to access a repository that had been upgraded/created by an
svnadmin of a newer minor version.
>
>
Re: can "svnadmin dump" tolerate read-only repository access?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 28, 2011, at 12:37, James Ralston wrote:
> Recently, Red Hat Enterprise Linux 5 updated its Subversion package
> from 1.5.x to 1.6.11.
>
> This exposed a *forwards* compatibility problem: the Subversion 1.6
> hotcopy command fails on Subversion 1.5 repositories:
>
> $ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $?
> svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory
> 1
>
> We tested if creating an empty db/fsfs.conf file will resolve this
> issue, and it does. And this issue seems to have been fixed in 1.6.13.
>
> But given that this very simple compatibility issue wasn't caught
> until two bugfix releases later, we're concerned that there may be
> other forwards compatibility issues that will bite us in the future.
The Subversion team's promise is that any Subversion 1.x client will be compatible with any Subversion 1.x server, and I would assume with any Subversion 1.x repository. If bugs are introduced that break that promise, I'm confident that those bugs would be fixed.