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

Re: Any FSFS rep-sharing experts out there?

From: Branko Cibej <brane_at_xbc.nu>
Date: Thu, 08 Oct 2009 18:47:47 +0200

Mark Phippard wrote:
> On Thu, Oct 8, 2009 at 12:40 PM, Branko ─îibej <brane_at_xbc.nu> wrote:
>>> 1) Why do we need to open this database when reading the repository?
>>> Such as for a checkout? My understanding is that the only time the
>>> cache is needed is when we are writing to the database. We want to
>>> see if there is an existing representation for the same hash. So why
>>> should we care if this database is locked when someone is doing a
>>> checkout?
>> The rep-cache database gets opened deep within svn_fs_fs__open and
>> svn_fs_fs__create. We don't really have a way to distinguish between
>> open-for-read and open-for-write in svn_fs_open. I can't form an opinion
>> right now on whether that's a serious omission or not, but in any case
>> adding an open-mode would be a huge conceptional change, of the svn-2.0
>> kind, IMHO.
> I am not a C programmer, so I am speaking from a position of ignorance
> here, but I do not see why we cannot just open the database at the
> same point where we actually need to use it. It seems like poor
> design to be opening the SQLite database every time the FS is
> accessed, when it is only needed when we are committing something.
> Especially thinking of people that have their repository on NFS or a
> NetApp or something

I'm sure we can. And it has nothing to do with choice of programming
languages. :)

You're right, though; doing this would most likely solve 99% of the
blocking problems seen on svn.apache.org. Even two simultaneous writers
aren't likely to interfere with each other too much.

I'll see about confirming this hypothesis.

-- Brane

Received on 2009-10-08 18:48:00 CEST

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.