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 09:23:53 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Christian Schmitt wrote:

Hi,
today I upgraded our CVS server on a Debian box to version 1.12.1
Since that time I get an error when checking out a project from that
machine:
cvs [server aborted]: Basis_Point_Value.htm,v is ambiguous; could mean
basis_point_value.htm,v or Basis_Point_Value.htm,v


You have similarly named but differently cased files in your repository and CVS doesn't know which one to pick. This is due to a fix I recently checked in for a problem where a recase from a case-insensitive system such as Windows would cause an assertion failure and archive corruption. Now when a CVS server finds two files that would be identical for the case-insensitive system, it refuses to go any further.

The immediate work-around is to rename or remove one of the archive files.

This only happens when accessing the CVS repository from a windows
machine.
I tried with a Win32 version:
Concurrent Versions System (CVSNT) 1.11.1.3  (Build 57a)
(client/server)
as well as two Cygwin versions:
Concurrent Versions System (CVS) 1.12.1 (client/server)
and
Concurrent Versions System (CVS) 1.11.5 (client/server)

Checking out the project on the Linux box itself works fine as well as
working from a Solaris machine using:
Concurrent Versions System (CVS) 1.11 (client/server)

This brings up a good point that I've been thinking about, however. 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.

Are there any cases where a case-insensitive operating system (OS X? Mark?) will recase the file name and cause the incorrectly cased file to be passed to the server, or can we count on the case not changing? If we can't count on the case not changing, could we rely on Entries on the client to pick the correct case?

The model I'm thinking of is that it is often possible to attach a case-sensitive file system to what we normall consider/refer to as case-insensitive operating systems. On occasion, a checkout, like `cp -r', could overwrite a file, but the client is the one that should know better, not the server.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
I will not barf unless I'm sick.
I will not barf unless I'm sick.
I will not barf unless I'm sick...

         - Bart Simpson on chalkboard, _The Simpsons_







reply via email to

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