>--- Forwarded mail from [EMAIL PROTECTED] >Steve McIntyre [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
