2 messages in com.perforce.perforce-userCase sensitivity.
FromSent OnAttachments
Will...@digintelligence.com15 Feb 1999 13:53 
Fred...@mydata.se16 Feb 1999 14:31 
Subject:Case sensitivity.
From:Fred...@mydata.se (Fred@mydata.se)
Date:02/16/1999 02:31:36 PM
List:com.perforce.perforce-user

# From what I understand modifying the metadata is your only option.

Meta: This type of question regarding case sensitivity is quite common. It interest me now because we are considering to use NT clients mixed with Linux clients. What surprised me was that I could find _no_ information about this at perforce web site. Not in the technical notes and not in the FAQs.

Did I miss something or is there really no info about case sensitivity problems when mixing *nix and NT clients?

I would think the question common enough to deserve at least an entry in a FAQ.

/Fredric

William Wishon wrote:

Does anyone know how to deal with case sensitive clients and a case insensitive server? We're running an NT server, mostly NT clients, and I have a Solaris client.

Here's the problem. The depot looks like this

//depot/TEST/one //depot/TEST/two //depot/TEST/three

then from a Windows NT client someone adds

//depot/test/four

which is fine if the client is case insensitive. The problem is with my Solaris client when I synchronize to the depot I end up with

~/TEST/one ~/TEST/two ~/TEST/three ~/test/four

on my local drive. Which is not what person who added the file to the depot meant, nor what I want to see on my local drive.

I checked our depot on the server and there's only one directory named 'TEST' and that directory has the case of the first addition, in this case 'TEST'. Somewhere in the rest of the metadata it is recorded that the case of the second addition is different than the case of the first. From listening to this list it seems that modifying a checkpoint behind perforce's back and then recovering it would be one possible solution. But is there a better way? And more importantly a way to prevent it from happening in the first place?

-Bill bill.wishon at digintelligence.com