I'd be inclined to agree here. One particularly common use case for having files with different casings is when a file is incorrectly cased on first commit. One runs cvs rm, renames the file then re-adds it (as following the "right way" of doing things). In this case, there is never a sandbox conflict as to which file is meant by the particular revision.
If there was to be a check on the cvs server, I would much prefer something which forced files on windows machines to be committed using the same case as an existing file on another branch. I frequently have problems with "build.bat" being created on one branch, and "Build.bat" being made on the trunk, then avoiding all the rcs_assert( != 0) errors that appear if things are not handled very sensitively. -----Original Message----- > The existing (I think) test cares about theoretical ambigity; my > proposed one cares only about the practical problem -- the > impossibility of stuffing two unrelated revisions into one > sandbox file. If an operation isn't trying to do that, > forbidding it on theoretical grounds seems pointlessly annoying. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
