Re: More case insensitivity issues

[Derek Robert Price]

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

Gianni Mariani wrote:

| Derek Robert Price wrote:
|
|> ...
|>
|> 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.
|
|
| Not good, but certainly better than what was there before !
|
|> 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.
|
|
|
| Take this case:
|
| key:
|
| csc - case sensitive client
| cic - case insensitive client
|
| 1) csc adds file "a.h"
| 2) poduct is released build is tagged BUILDA
| 3) csc removes a.h
| 4) tree is tagged BUILDB
| 5) cic adds totally new file "A.h" - magic happens - is BUILDA broken ?
|
| what happens on merges i.e. either client does cvs update -j BUILDB -j
BUILDA ?
|
| In other words - what are people going to be upset about ?


The whole point of this solution is that when cic attempted to add A.h,
a.h was actually resurrected.  Your backout command would attempt to
readd the a.h on either client when it already existed.

|> 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.
|
|
| Are you implying here that there is a mode where the cvs "filesystem"
appears to be all case insensitive ?


The CVS server pretends, mostly, to be on a case insensitve filesystem
when a client claims to be on a case insensitive filesystem.

|> 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.
|
|
| I might get upset, just not sure what to get upset about yet .... :-)


Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
Suburbia:  Where they tear out the trees and name the streets after them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/jaJ7LD1OTBfyMaQRAoY5AJ9f+nKK0FINlyqrJ0W01CYxttThNQCg4qYF
GVDIcl0Hsm2M4ZkCm6y6xFE=
=RjzQ
-----END PGP SIGNATURE-----