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

Re: [RFC] FSFS filesystem options (long, sorry)

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-03-05 20:29:24 CET

On Mon, Mar 05, 2007 at 11:22:50AM -0800, Karl Fogel wrote:
> > Sure. Offline is the key here, though, even if it is a quick operation.
> > (We probably _should_ write a script though).
> Just to play devil's advocate: why not just have Subversion
> auto-upgrade repositories? It can lock others out while it does it.
> It's not clear to me that the upgrade has to be atomic, even. You go
> looking for the revision in the new place, you don't find it, so next
> you go looking in the old place...

Wow. That's an interesting idea, and apart from the change to
db/format, would probably work, too, no locking required as long as we
were careful. You could probably trigger a mass-migration just by running
'svn log -r0:HEAD', too.

I don't see any way to lock existing readers out while we tweak
db/format though - FSFS annoyingly doesn't support exclusive locking.
So we might need that to be an offline operation.

> I gues what I'm trying to say is: just because a repository format
> change feels intuitively like a big deal, doesn't mean we must assume
> it actually is one. Let's think creatively. It may be that this can
> all happen completely transparently to the user/administrator. If
> that's possible and not too costly, it's certainly the right course.

Sounds good, if a little scary.


  • application/pgp-signature attachment: stored
Received on Mon Mar 5 20:29:38 2007

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

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