bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs [server aborted]: <file-name>,v is ambiguous


From: Derek Robert Price
Subject: Re: cvs [server aborted]: <file-name>,v is ambiguous
Date: Tue, 24 Jun 2003 12:57:44 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Larry Jones wrote:

Derek Robert Price writes:
Larry, you recently expressed a wish to me that case-insensitive file systems would just go away. Does anybody have a good feel for what would happen if we removed case-insensitivity awareness from the server altogether and let the client deal with it? I think that since Windows is now (or always was?) case-preserving, there mostly shouldn't be a problem, aside from possibly having to educate users that they have to get the case correct on the initial checkout.

There are other case-insensitive systems that are *not* case preserving,
notably VMS (and the IBM mainframe systems if whoever is working on
porting CVS to that environment ever succeeds).


Darn.  I think I have a partial solution, though.

In the following, recased is an abbreviation for a file being referred to which already exists with the same name in a different case.

9 Cases:

Case sensitive client:
1. w/ case sensitive server
& 2. w/ case insensitive/case preserving server
& 3. w/ case insensitive/case folding server:
All the case-sensitive clients may be safely ignored, as they will either agree with a case-sensitive server or the server will respond with "file already exists" errors when they attempt to add recased files.

Case sensitive server:
4. w/ case insensitive/case preserving client:
No handling on the server. This should allow clients which are on case insensitive file systems to deal with files with recased names the way it wants. Files that don't exist in the local workspace can still be referred to (for status, log, other commands with -r, etc) by preserving the case of the user request when sent to the server and not sending files despite a local match when the request case isn't identical to the local case.

5. w/ case insensitive/case folding client:
No handling on the server. The client would need to maintain a table, perhaps in an Entries.key file, to translate local file names to appropriate names to send to the server. Either files that exist on the server with recased versions on the client can not be referred to with the local commands (the r* commands could still be used), or the client could require the case in the Entries file to be correct to locate a file.

Case insensitve/case preserving server:
6. w/ case insensitive/case preserving client:
& 7. w/ case insensitive/case folding client:
No handling necessary on the server or client. All possible recases of a file name can point to only one file on both the client and the server.

Case insensitive/case folding server:
8. w/ case insensitive/case preserving client:
9. w/ case insensitive/case folding client:
As 6 & 7.

Note that it would be up to the client to decide what to do with the checkout of a recased file. It could rename it according to some scheme thought unlikely to intrude on the user namespace and track the rename via an Entries.key file in both cases 4 & 5.

Note also that none of these cases require server handling. Thus backwards compatibility can be preserved by having the new clients not declare themselves case insensitive via the protocol. Users who complain about the old behavior could then simply upgrade a client to one of the newer, case aware ones. Case aware clients would also work with old servers since no handling is required on the server end and they would not declare themselves case insensitive to the old server.

I think someone really needs to think about the 9 possible cases -- case
insensitive but case preserving, case insensitive case folding, and case
sensitive clients and servers -- and figure out how CVS should behave. Once we've decided what it's *supposed* to do, then we can make it do
it.  "Let's try this and see how it works out" is how we got where we
are now, I'm not convinced it's a viable method for improving the
situation.


Well, that's why I asked.  :)

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
Mud is not one of the 4 food groups.
Mud is not one of the 4 food groups.
Mud is not one of the 4 food groups...

         - Bart Simpson on chalkboard, _The Simpsons_







reply via email to

[Prev in Thread] Current Thread [Next in Thread]