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

Re: AW: SQLite locking for WCNG on NFS

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 27 Feb 2012 13:12:36 +0000

Branko Čibej <brane_at_apache.org> writes:

> All of these scenarios assume there is a mechanism that determines
> whether simultaneous access to the working copy by two threads of
> control is actually happening or not. You say that the only possible
> such mechanism is "the user". Nonsense.
>
> We're already relegating too many choices to "the user". The only really
> visible result is that Subversion has a myriad knobs that the average
> user doesn't know how to use properly.

I suppose there are a few settings relating to password storage but I
can't think of many others.

> libsvn_client /should/ be able to make these choices, and even negotiate
> changes in locking policy. Sure it's more design and implementation
> work, but on the plus side, you don't have to explain to any number of
> users why or when they have to change an obscure client-side setting
> that they don't even understand properly.
>
> In all this thread I've not seen a single though about changing the
> locking mechanism on existing connections when parallel access is
> detected. Is it possible? How hard is it to do? No, let's not think
> about that, we have an all-purpose hammer called "the user" so we don't
> have to make hard decisions in code.

As far as I can see negotiating locking between clients would involve
some sort of locking daemon and a network protocol. I'm not even sure
it would solve the problem since it would introduce new latencies. I
don't want to try writing that. Do you have some other mechanism in
mind?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-27 14:13:21 CET

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