[p4] line endings
william_ivey at bmc.com
Tue Aug 14 11:39:46 PDT 2007
> 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
> "unix" mode.
Unfortunately, that doesn't solve all the problems either.
In our case, developers have to be able to create and
submit files in both formats, and our build machines
(unix) have to retrieve them as submitted. That pretty
much requires the file on the server to be exactly as
intended, with no client conversion either way.
The only real issues we've had are when developers ignore
the policy of setting their clients to "unix" and even
that has limited impact unless they pass files around
outside of Perforce (which we discourage unless they only
submit the original copy from the original workspace).
Shared would be the best solution if there was also a
file type that allowed the default behavior to be bypassed
for specific files. There actually aren't that many files
that MUST be Windows text, at least in our system, but
there are a LOT of files that cannot be. Setting a file
type for a few specific files wouldn't be a hardship.
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of G Barthelemy
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