>--- Forwarded mail from [EMAIL PROTECTED]
>pohl <[EMAIL PROTECTED]> writes:
>> Let me ask: what is it about locking and concurrency that makes them
>> mutually exclusive? Other software manages to find design patterns that
>> allow them to handle configurable policies. (The X11 mantra "mechanism
>> not policy" is a great example) Why not CVS?
>Small tools. Would you want find and grep to be the same binary? They do
>two very different things. Combining the two might offer some rather nice
>recursive grep commands, but at the cost of making both programs harder to
>maintain as a combined program and at the cost of a breakdown of what
>could (and currently is) a clearly defined interface that lets you plug
>any other program into find, including another variety of grep.
The analogy I would use rather than find/grep is more like cmp/comm/diff/diff3.
These all do similar tasks, but in different ways. Do we want all of their
in a single, unified, differencing tool? Some people might, others won't.
In the case of CVS vs. locking, some people want a unified "version control
tool" and are willing to put in the complexity that's needed to fulfill
their needs. One of the benefits of such a tool is that the working
environment is much more cohesive.
>CVS sucks at locking. Its original design didn't take locking into
>account. Adding locking into CVS seems to me to be like adding grep into
>find; it adds some functionality for people, but the two concepts *could*
>remain orthagonal. Rather than doing that, why not add a -print0 flag and
>write a little program called xargs, and then use the existing grep? In
>other words, design a really nice locking system with a separate
>implementation and figure out a good way to have it *modularly* interact
>with CVS via a well-defined interface that could be useful for other
>things as well.
Version control is version control. So there are variations on a theme
with regard to certain details like whether or not locking is provided.
Is it really that difficult to permit a commit only if a) a user has
declared intent to do so, b) the user must be up to date before making
such a declaration, and c) only one user is permitted to make such a
declaration on a given branch in a file? I don't think so. (Note that
in the context of CVS, such capability is intended to be an option, enabled
on a per-file basis, not by default.)
>I think that if someone did that, they'd encounter much less in the way of
>opposition.
I think people are having too much of a knee-jerk reaction: He mentioned
LOCKING! Locking is BAD! Don't even THINK about it!
The truth is, a well-designed and integrated locking capability has its
place, and ignoring the cases where it's needed is not the answer.
>--- End of forwarded message from [EMAIL PROTECTED]
