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?
On 2/28/2011 10:37 AM, James Ralston wrote: 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 dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: can "svnadmin dump" tolerate read-only repository access?
On 2011-02-28 at 10:49-08 David Chapman 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?
On 2/28/2011 11:00 AM, James Ralston wrote: On 2011-02-28 at 10:49-08 David Chapman 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 dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: can "svnadmin dump" tolerate read-only repository access?
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.
Re: can "svnadmin dump" tolerate read-only repository access?
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?
'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?
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?
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.