updated to 1.11.6 (from 1.11.2) now have problems on windows

[Matthew Herrmann]

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.