More case insensitivity issues

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fixing the assertion failure and repository corruption on an attempted
recase (remove of file1; add of FILE1) from a case insensitive
filesystem exposed another bug:

The add now finds the previous version of the file, despite the
different case, and resurrects it.  This is as intended.  It is parallel
to the operation of all of the other CVS commands when run from a case
insensitive client - it first looks for a file cased as specified and if
one cannot be found it then finds any file spelled correctly in a
different case.

The problem is that, on a subsequent update, the case of the entry in
the CVS/Entries file on the client no longer matches the case of the
file on the server, which still has the original case.  This causes
"move FILE1 - it is in the way" errors from the client on updates from
the server of "file1".  This is certainly not desirable.

I've been thinking about this problem, and I've come up with two
possible solutions:

One solution is to keep most of the behavior the way it is, which
disallows a recase from Windows and other case insensitive clients, but
send commands on commit of an add to correct the case of the file on the
client and avoid the "in the way" errors.  I like this solution best,
since it maintains the behavior parallel to the rest of the CVS commands
in regards to looking up file requests from case insensitive clients,
finding differently cased files and assuming that resurrecting those
files was the intended result.  I think this solution will take a little
longer to implement,
however, on the order of a week or two of total dev time.

The second solution is to assume that a user performing a `cvs add' from
a CVS client knows what they are doing when they request a different
case from any file in the repository and allow the recase, causing an
add of the new file with the new case.  This fix would enable the most
functionality, but users on case insensitive file systems might be
surprised by the change in the way the server does file lookups compared
to the other CVS commands.  This fix might or might not require less
work.  Something similar to this was happening before the assertion
error fix - the first lookup created a new file and a second case
insensitive lookup determined that there was case ambiguity and an
assertion failed.  I'm sure I could find an alternative way to work
around this issue, but I'm not sure how long that will take.

I suppose that an argument could be made that assuming the user was
requesting the case they desired in solution two was actually the same
behavior expected of the other commands in the case of an add - since a
file name in any case can be created, any requested case "matches"
literally during an add.  We don't care during the matching phase
whether the "match" happens to cause a create or a resurrection.

Either solution is likely to upset some users.  I was hoping to get a
good feel for how many were on each side of the issue by asking info-cvs
& bug-cvs and maybe even elicit definitive arguments as to why one
solution should be preferable to the other.

Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
"I wish you and yours every joy in life, old chap, and tons of money,
and may you never die till I shoot you."

~    -James Joyce, "Dubliners"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/jYrQLD1OTBfyMaQRAlLpAKCSRAcJWsljwuu3VSJAsF6A/AW/LQCgvDnA
D4rSBr70hEBQz1uvN6VV/PQ=
=hEiA
-----END PGP SIGNATURE-----