On 19 Dec 2005, at 21:27, Jim Fulton wrote:
IMHO the process is straightforward and easy (except for the time
it will take),
That fact alone adds complication, as that down time needs to be
OK, well, the only complication is setting a date really. Someone
decides and publishes it on the different lists, end of story.
> and there is no problem reverting to the previous state:
- run svnadmin dump on the old repository
- move the old repository aside
- create a new repository with fsfs backend
- run svnadmin load to load the data into the new repository
I presume you also need to disable access to the repository while this
is going on. That means there are three input paths (viewcvs, svn:,
svn+ssh:) that need to be disabled. Maybe that's just a matter of
renaming the repo.
viewcvs is disabled by either shutting down Apache or putting up some
meaningful error page. svn access is disabled by editing /etc/
xinetd.d/svn and restarting xinetd. svn+ssh can be disabled by
editing /etc/ssh/sshd_config to restrict access. This is a matter of
At no point would any data be in danger. The problem I see on the
current box is hard drive space. I'm not sure the remaining space
is enough to hold a complete dump *and* the new repository along
with the old one.
The whole repository is only about 800 megs. There are over 8 gigs
free. Are the dump file or the file-based repo much larger in
size the the Berkeley database?
I'm not sure, really, but knowing the current size (which I had not
checked) makes me confident we're fine on that front.
BTW, thanks for volunteering for this! It will be great not to
fool with the Berkeley DB anymore. :)
Umh, more like force-volunteered now ;) Which is fine, but in return
I'd like someone else (maybe you?) to herd the cats and come up with
a time frame where this can be done, and communicating it. I'll do
everything on the technical side. Sound like a deal?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -