>--- Forwarded mail from Jim.Hyslop@xxxxxxxxxx
>Steve McIntyre [mailto:steve@xxxxxxxxxx] wrote:
>> Another point I'd like to make: labels are case-sensitive
>> already. Live with it.
>I think you missed my main point: *why* should the user have to "deal with
>it?" Just because "that's the way it works"? Well then, let's *change* the
>way it works, so people don't have to "deal with it." Make the computer deal
>with it.
Having experienced the way it works both ways, I personally prefer the Unix
way. (Unix was not my first OS, by the way.)
The problem here is as much a matter of taste as anything else. Half the
users want case-senstivity, the rest want case-insensitivity with case-
preserving behavior. Because computing resources are shared, then half
of the users are bound to be unhappy in a shop that requires
interoperability between systems. There's no workable solution to the
problem at the filesystem or OS level, so it falls onto the shop to set
its own policy.
I think that the proper solution is not to change the OS, but to simplify
CVS. CVS should support case-sensitivity, but provide more hooks so that
the shop can enforce its own naming policy. That way, pure Unix shops
get what they want by default. Canned triggers can enforce policies such
as "no upper-case letters in a name" or "no two files in the same directory
can have names that differ only by case". The triggers must apply at the
points where they make the most sense.
At present, such triggers can be invoked only at commit time. In my opinion,
that is too late to be any good for enforcing naming conventions, because
by that time there may have been significant work done that depends on the
new file's name. (Consider, for example, the case where a C header file is
refactored, and a fundamental data structure is moved to the new file. If
local policy is to disallow nested #includes then many source files require
modifications to pick up the new file. If two users add header files that
differ only in case concurrently, then a significant amount of rework is
needed to resolve the conflict. Although we could argue that this specific
example is a project management problem, most of us have seen variations
of the problem.)
In my opinion, the "cvs add" command should be modified to invoke a trigger
and then reserve the name in the repository. The "cvs remove" command should
be modified to invoke a trigger that enforces removal policy (and cancels
reservations if no versions have been committed to the file).
>--- End of forwarded message from Jim.Hyslop@xxxxxxxxxx
|
