Perforce FAQ for System Administrators

Contributed by Jeff Bowles

Note - the intended audience for this FAQ is a system administrator who knows some Perforce commands as a user, but needs more information to be able to do some Perforce administration tasks such as setting up a new Perforce user or dealing with restarting the Perforce server after a recovery from a catastrophic disk crash.

This FAQ assumes that there is a Perforce Administrator who knows some of the more complex parts of Perforce, who can provide help, counseling, and deal with policy-specific issues....
 
 
Client Stuff
Non-admin Usage Stuff
Policy Stuff
Admin Issues (backups et al)

 

    Background
        The machine on which the "p4" client software is run dictates the CR/LF behavior. If you extract the files from the Perforce depot using the Windows version of "p4" it'll have CR+LF as line separators for text files, even if you physically wrote the files to a Unix disk that was remotely mounted using NFS or Samba. (This means that the Macintosh version of the "p4" client uses CR for end-of-line, always, and the Unix client uses LF for end-of-line.)
         
    How do you tell if a file is "text" or not?
       
      If a file's checked in, run p4 file XXX where XXX is the name of the file. You'll get output of the form:
      //depot/dev/src/GNUdepends.def#3 - edit change 20027 (ktext)
      //depot/dev/src/GNUmakefile#188 - edit change 21753 (text)
      //depot/native/events/EventsGenCtl.bmp#3 - delete change 1103 (binary)
      Unless it was specified when the user ran p4 add, the local Perforce client guessed based on the first few bytes of the file. (NUL characters and non-ASCII are dead giveaways - if they're present, the file has to be binary.)
       
    What if you it guessed wrong, and you need to change the type of a file so that it does end-of-line processing?
       
        You'll need to open the existing file for editing, change its type, and submit the change:
          p4   edit  -t text  //depot/native/events/EventsGenCtl.bmp
          p4   submit
        In this case, you'll probably be treating a .bmp file like it's text, which is pretty silly, but this gets the point across. You can go back and forth with a file, if you choose - change the type of a file from text to binary, or binary to text. (The k in ktext, above, means "expand keywords like $Id: //depot/internal/staff/stella/P4AdminFAQ.html#18$ in the contents when it's fetched from the depot. There are other types, also: p4 help reopen lists 'em. There's a type for "long text files that are computer-generated such as PDF files" - be sure to note that one.)
         
    Ways to force it to not interpret end-of-line, to leave the file contents alone:
       
        Change the file type from text to binary, and make sure that it's byte-for-byte the exact contents you want.
         
    How do I get Unix end-of-line processing behavior on my Windows Perforce client?
       
        Short answer: I don't know. Certainly, you can edit the files on Unix, store what you want there, and change the file type to "binary" to guarantee that the contents aren't munged when you fetch 'em with the Windows client. that's probably the fastest, but ugliest way.

 
 
 
 
 

 
 

 

 


Last modified on 21 September 1998.