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