[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-03-05 23:50:46 CET

Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:
>> There's deliberately no way to lock out readers. This is so that
>> readers don't have to have permissions to get a repository lock. The
>> repository needs to be consistent from a reader's perspective at all
>> times, by design.
> I understand. I guess that means that bumping the db/format file needs
> to be an offline operation then, so we can guarantee that old readers
> have stopped reading.

Remember that it's okay to have multiple representations of the same
historical data present at the same time -- readers don't care which
source is behind the data they're getting...

> So lets say we do implement this transparent upgrade path - how does the
> repository admin mark the repo as 'safe to upgrade'? Should we just say
> "manually take the repo offline and run this tool (which does 'echo N >
> db/format')"?

...so upgrading the format can happen whenever you're ready to make
new connections from older clients return errors. And then *after*
the repository format has been upgraded, the old representations can
be cleaned out.

We should approach this whole thing with the attitude that it can be
done totally transparently for everyone, users and admins. Let's look
for ways to make that happen; maybe we'll discover that there's some
bit that has to be done manually after all, but why cede that ground
before we're absolutely forced to?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 23:51:09 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.