[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More case insensitivity issues
Derek Robert Price
Re: More case insensitivity issues
Thu, 16 Oct 2003 10:42:58 -0400
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
-----BEGIN PGP SIGNED MESSAGE-----
Incidentally, the other side effect of this problem is that *info
scripts running on case sensitive servers are currently passed
incorrectly the names of new added files. Even though file1 might be
resurrected by a command from a case insensitive client, for example,
loginfo could be passed FILE1 as the filename of the new file.
Either of the solutions below would fix this. Solution 2 by virtue of
making the current "incorrect" name being passed to loginfo the correct
one without altering it and solution 1, presumably, by correcting the
name in the internal CVS data structures when it was determined that
corrective commands needed to be sent ot the client and before it got
passed to loginfo.
I'm starting to think I actually prefer solution 2. It is much more
elegant. Any of the consistency buffs out there want to argue with me?
Derek Robert Price wrote:
| 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.
Get CVS support at <http://ximbiot.com>!
My karma ran over my dogma.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----