Jens Vagelpohl wrote:

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 scheduled.

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

It's also used for CVS.  (Maybe mailman too?)

> or putting up some
meaningful error page.

Which has to be written.

> svn access is disabled by editing /etc/
xinetd.d/svn and restarting xinetd.

Uh huh.

> svn+ssh can be disabled by  editing
/etc/ssh/sshd_config to restrict access. This is a matter of minutes, really.

I didn't think you could use sshd_config to restrict use of a single
program.  ssh access is still needed for CVS and for people logging
in to do other work (e.g. mailman admin).

Moving the repo seems a lot easier. :)

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.

Of course, you'll want to do a dry run to make sure.

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?

Sure. Thanks again. :)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to