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