Branko Čibej <br...@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
