[p4] line endings
jsmith at medplus.com
Tue Aug 14 14:07:11 PDT 2007
I do know there are issues working with mixed environments because the
Perforce clients on Windows adjust the line endings without checking
what is already there. This can result in files having extra 0x13 at
the end of the lines. In other words, if you set your client line
ending to Windows and sync a file that has Windows endings in the depot,
you will get an extra one tacked on. The Perforce client doesn't look
at the file to see that the ending is already what you want. At least
this was the case when I last checked the 2006 series clients.
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Weintraub
Sent: Tuesday, August 14, 2007 12:52 PM
To: G Barthelemy
Cc: perforce-user at perforce.com
Subject: Re: [p4] line endings
On 8/14/07, G Barthelemy <gb.perforce at googlemail.com> wrote:
> I find that "depot pollution" (i.e. CR/LF line endings in the depot)
> creeps in very quickly when the users are in a mixed environment,
> typically using Perforce on a Windows host but with the workspace
> stored on a CIFS share accessible from a Unix / Linux box (usually
> where the build environment resides and is run from).
I'm not sure why depot pollution happens. According to Perforce:
> On the server side, Perforce processes all text files using Unix-style
> LF line-endings. Although Perforce stores server archive files on disk
> in the operating system's native line termination convention (CR/LF on
> Windows, LF on Unix), all line-endings are normalized to Unix-style LF
> line-endings for internal Perforce Server operations such as sync,
> submit and diff.
> On the client workspace side, Perforce handling of line-endings is
> determined by a global option for each clientspec. When text files are
> synced to a client workspace with p4 sync or submitted back to a
> Perforce Server with p4 submit, their line-endings are converted as
> specified in the clientspec option for line-end treatment.
If this is the case, then Perforce should always be normalizing each
file before checking in and out, and sending the files to your client
with the correct line endings. Any file that is text should be forced to
be normalized. Any file with CVS Keywords should be cleaned up.
However, this doesn't appear to be happening -- at least in a consistent
I had a lot less trouble with line endings in Subversion. Plus,
Subversion has a file attribute that allowed you to specify on a
file-by-file basis the line endings. This way, VS files could be forced
to have CR/LF endings while Makefiles and Unix shell scripts would be
forced to have LF endings. I think Subversion otherwise stored all text
files (despite platform) with Unix line endings.
qazwart at gmail.com
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user