[p4] line endings

Ivey, William william_ivey at bmc.com
Tue Aug 14 12:43:18 PDT 2007



> 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.

There is no such thing as a "normal" text file. On any
given system, Unix or Windows, there can be some of each
(and some Mac files, etc.).

The problem, in my experience, arises from user
inconsistency. People pass files around from systems of
one flavor to another. People change their client's
line ending setting then submit without refreshing the
sync file. Some people just decide to change the text
format because they have no clue it matteres. People 
ignore my warnings - a LOT.

The experienced users never seem to have a problem with
it. Sure, once it a while someone goofs, but they tend to
catch it, too. Usually it's the new-ish java developers who
have never developed anything that needed to run on more
than one platform, or at least never had to deal with any
platform-specific issues. (A few of them actually get angry
when such issues are pointed out to them - it works on their
development box, why I am I bothering them with details?)

-Wm


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Weintraub


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 basis.

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.

--
David Weintraub
qazwart at gmail.com
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list