On 22.02.2012 10:25, Philip Martin wrote:
> Branko Čibej <brane_at_apache.org> writes:
>> On 20.02.2012 09:51, Markus Schaber wrote:
>>> What about an "-exclusive" general option to the svn command line client, which triggers exclusive wc access for that specific command invocation / session?
>> And you expect users to know when to use it, and especially when /not/
>> to use it?
>> Come now. Controlling performance tweaks from the user interface is
>> hardly good design.
> Not sure I agree, I don't see how anything other than the user can make
> the choice.
> The user has more information than the application can ever have. If
> the user wants to be able to run two subtree updates in parallel then
> exlusive locking must not be enabled. If the user wants to run status
> during an update then exclusive locking must not be enabled. If the
> user is happy with one process having exclusive access then exclusive
> locking is a major performance gain. If the user isn't making that
> decision how else can it be made?
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.
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.
Take this line of reasoning to its logical conclusion and you don't need
a version control system, either; nor computers. Wouldn't life be so
much easier for all of us then. :)
Received on 2012-02-26 11:16:54 CET