Re: More case insensitivity issues

[Derek Robert Price]

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

Okay.  Solution #2 it is, to be implemented shortly on stable.  Speak
now or forever hold your peace if you have objections.

Derek

Derek Robert Price wrote:

| 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
|
| 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.
| |
| | Derek



- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
The home town of American Olympic Champion skier, Picabo Street, has
decided to recognize their "favorite daughter" by naming the new wing
of the local hospital in her honor.  That wing, which will include a
state-of-the-art Intensive Care Unit, will hereafter be known as the
"Picabo, ICU".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/lTLZLD1OTBfyMaQRAhfCAKC+egHPcVBvHO9dYXwv2Iu6I8pewwCfVS1L
loBFBjlDJ07hj7MZ6TrTb7c=
=Mv8V
-----END PGP SIGNATURE-----