[p4] line endings
gb.perforce at googlemail.com
Tue Aug 14 08:54:21 PDT 2007
On 8/14/07, David Weintraub <qazwart at gmail.com> wrote:
> Normally, Perforce stores line endings on the server as "LF" (Unix
> style), and normalizes them based on your client (i.e., when a file is
> sent to your system, the line endings are changed to "CR/LF". In
> theory, it doesn't matter what your client does since Perforce will
> automatically fix the line endings anyway.
> However, it seems that I've seen Perforce files stored on the server
> with CR/LF endings, but these could be a result of a CVS to Perforce
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).
The problem starts when the user sets his client to "unix" LineEnd
mode, because the extra return-carriage due to the default "local"
LineEnd setting made the build on the Unix side fail (the extra CR
comes from the fact that the client is sync'ed from Windows). Now, a
p4 client on a Windows platform with unix LineEnd mode wouldn't be a
problem in itself if all the editors respected the file's current line
ending, but that's wishful thinking (and risky). Actually a surprising
number of Windows based editors do not temper with line endings, but
you only need one... and BTW, one of those is p4v/p4merge (and
p4WinMerge if not configured): both change the line ending of the
lines they touch.
Once an opened file has CR-LF line endings, then only a client in
"share", "win" (or "local" from a Windows platform) would convert
those line endings on the fly (to LF) as the file is submitted. In all
other cases (i.e. client in "unix" or "local" from a Unix/Linux
platform) then the file with CR-LF gets stored "as is" in the depot
and you end up with "depot pollution".
The above applies whether the client is dual-rooted or not.
To cleanup a batch of files (say a whole changelist) that would have
been submitted with CR-LF, you just need to open all the relevant
files and submit them "unchanged" in a client set in "share" LineEnd
mode. That'll perform the necessary conversion back to LF. As an
extension to this trick, I advise Unix based users to set their client
to "share" (rather than "local" or "unix"), even if they do not
dual-root their client with Windows, just to make them contribute to
depolluting the depot.
OP, the answer to your question is to set the client LineEnd mode to
"share". You'll get Unix line endings in the client (if the depot is
not already polluted), and you'll have the safety of converting
whatever CR-LF would have crept in back to LF upon submit, unlike the
More information about the perforce-user