[p4] line endings

[Kilaru Sambaiah]

Hi All,
I have a question with line endings. I am using windows client p4win to
communicate with perforce
server. I wanted Unix line endings on sync. How do I set it up on my
client?
thanks and regards,
Sam

[David Weintraub]

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

Normally, the default "local" should work for the LineEnd: field no
matter what platform you're using. However, you can set the LineEnd:
field to "unix", "win", "share", and "mac" (although even Mac no
longer uses "mac"). You may want to set your LineEnd field to use
"unix" or "share". "Unix" is good if all of the tools you use
recognize Unix line endings (like VI and Eclipse). However, if you use
VisualStudio, you'll be better with "share".

See Tech Note 63 for a full explanation.
<http://www.perforce.com/perforce/technotes/note063.html>

See <http://www.perforce.com/perforce/doc.072/manuals/p4guide/02_config.html#1082357>
on how to configure LineEnd field in your client.

Post by Kilaru Sambaiah
Hi All,
I have a question with line endings. I am using windows client p4win to
communicate with perforce
server. I wanted Unix line endings on sync. How do I set it up on my
client?
thanks and regards,
Sam
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Ivey, William]

The last time I looked at the delta files, changing the
line endings of a file created a line-by-line delta for
it.

This was using "unix" on the client which effectively
does no translation between server and client, even on
Windows. (If the file is stored as unix on the server,
that's what you get, but if it stored as Windows, you
get it that way.)

I prefer the unix setting because we have to manage
files in specific formats for both Windows and Unix,
and other settings will mask the actual file content
on at least one system. That has caused a lot of
headaches. (And it makes it very difficult to generate
Unix files on Windows, or the other way around.)

It's not been a problem with Visual Studio since it
doesn't really care about most files, and those it
does care about are generated on a Windows system
to start with and rarely manipulated on any other
kind of system.

-Wm


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

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

Normally, the default "local" should work for the LineEnd: field no
matter what platform you're using. However, you can set the LineEnd:
field to "unix", "win", "share", and "mac" (although even Mac no
longer uses "mac"). You may want to set your LineEnd field to use
"unix" or "share". "Unix" is good if all of the tools you use
recognize Unix line endings (like VI and Eclipse). However, if you use
VisualStudio, you'll be better with "share".

See Tech Note 63 for a full explanation.
<http://www.perforce.com/perforce/technotes/note063.html>

See
<http://www.perforce.com/perforce/doc.072/manuals/p4guide/02_config.html
#1082357>
on how to configure LineEnd field in your client.

[Jeff A. Bowles]

I always understood it as "the deltas on the server are stored in
server-native format for speed, but a Perforce user should not know or
care how the server's storing it."

-jab

Post by Ivey, William
The last time I looked at the delta files, changing the
line endings of a file created a line-by-line delta for
it.
This was using "unix" on the client which effectively
does no translation between server and client, even on
Windows. (If the file is stored as unix on the server,
that's what you get, but if it stored as Windows, you
get it that way.)
I prefer the unix setting because we have to manage
files in specific formats for both Windows and Unix,
and other settings will mask the actual file content
on at least one system. That has caused a lot of
headaches. (And it makes it very difficult to generate
Unix files on Windows, or the other way around.)
It's not been a problem with Visual Studio since it
doesn't really care about most files, and those it
does care about are generated on a Windows system
to start with and rarely manipulated on any other
kind of system.
-Wm
-----Original Message-----
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
conversion.
Normally, the default "local" should work for the LineEnd: field no
field to "unix", "win", "share", and "mac" (although even Mac no
longer uses "mac"). You may want to set your LineEnd field to use
"unix" or "share". "Unix" is good if all of the tools you use
recognize Unix line endings (like VI and Eclipse). However, if you use
VisualStudio, you'll be better with "share".
See Tech Note 63 for a full explanation.
<http://www.perforce.com/perforce/technotes/note063.html>
See
<http://www.perforce.com/perforce/doc.072/manuals/p4guide/02_config.html
#1082357>
on how to configure LineEnd field in your client.
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Ivey, William]

The user shouldn't, but the admin might wonder why their
delta files are growing by leaps and bounds.

The text you quoted refers, I believe, to the behavior of
clients with respect to what is on the server, but if you
actually submit a file with all line endings changed, you
end up with a delta of every line in the file.

One common route to this is when someone on Windows passes
a file to a unix user for review and submission from their
environment.

-Wm

-----Original Message-----
From: ***@gmail.com [mailto:***@gmail.com] On Behalf
Of Jeff A. Bowles
Sent: Tuesday, August 14, 2007 1:13 PM
To: Ivey, William
Cc: perforce-***@perforce.com
Subject: Re: [p4] line endings

I always understood it as "the deltas on the server are stored in
server-native format for speed, but a Perforce user should not know or
care how the server's storing it."

-jab

[G Barthelemy]

Post by David Weintraub
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
conversion.

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
"unix" mode.

[David Weintraub]

Post by 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).
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
***@gmail.com

[Ivey, William]

Post by David Weintraub
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-----

Post by David Weintraub
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).
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
***@gmail.com
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Qazwart]

Post by Ivey, William

Post by David Weintraub
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.).

That's the reason I said "normalizing" instead of what type of file
it should be. If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings, then when a
TEXT file is checked in, whatever line endings are used, they should
be translated to the line endings that machine uses. If I checkout a
file, the line endings should "convert" (if necessary) to the line
endings that are normal on my machine.

In a source control system, all files are considered "text" unless
there is a reason to consider them otherwise. I can only think of two:
Heuristic evidence on the file suggests it is not pure text (i.e.
contains characters other than the around 90 text characters), and
the file itself is marked as a binary file.

I've used Subversion, and I know that it seems to handle the line
ending situation much better.

Post by Ivey, William
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.

Nothing you stated should cause a problem (the emphasis on SHOULD).
When a file is submitted, the server should scan and replace any
necessary line endings unless the file is marked as binary. This
should happen no matter what line endings are used in your file, or
whatever line endings you client is using.

--
David Weintraub
***@weintraub.name
***@gmail.com

[Ivey, William]

Post by Qazwart
If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings,
then when a TEXT file is checked in, whatever line endings
are used, they should be translated to the line endings
that machine uses. If I checkout a file, the line endings
should "convert" (if necessary) to the line endings that
are normal on my machine.

I thought I was clear that this is exactly what I do not
want to happen. No matter what the client machine is, we
MUST be able to sync and submit text files in ANY format
we need no matter what kind of machine the client is hosted
on. Nothing else is acceptable since it would prevent us
from building the multiple-platform images we have to ship.
(Or at least complicate an already complex task to the point
of unacceptable risk.)

-Wm


-----Original Message-----
From: Qazwart [mailto:***@gmail.com]
Sent: Tuesday, August 14, 2007 11:56 PM

That's the reason I said "normalizing" instead of what type of file
it should be. If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings, then when a
TEXT file is checked in, whatever line endings are used, they should
be translated to the line endings that machine uses. If I checkout a
file, the line endings should "convert" (if necessary) to the line
endings that are normal on my machine.

In a source control system, all files are considered "text" unless
there is a reason to consider them otherwise. I can only think of two:
Heuristic evidence on the file suggests it is not pure text (i.e.
contains characters other than the around 90 text characters), and
the file itself is marked as a binary file.

I've used Subversion, and I know that it seems to handle the line
ending situation much better.

Post by Qazwart
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.

Nothing you stated should cause a problem (the emphasis on SHOULD).
When a file is submitted, the server should scan and replace any
necessary line endings unless the file is marked as binary. This
should happen no matter what line endings are used in your file, or
whatever line endings you client is using.

--
David Weintraub
***@weintraub.name
***@gmail.com

[Pavloff, Alex (IE) @ SONOMAEO]

I've got a few multi-platform issues also -- they are very sensitive to
line-endings in text files.

Easy solution? Change the filetype from "text" to "binary+D" on the
affected files.

Presto, Perforce doesn't do anything to the line-ends, but still uses
delta compression.

-Alex

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Ivey, William
Sent: Wednesday, August 15, 2007 8:16 AM
To: perforce-***@perforce.com
Subject: Re: [p4] line endings

Post by Qazwart
If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings,
then when a TEXT file is checked in, whatever line endings
are used, they should be translated to the line endings
that machine uses. If I checkout a file, the line endings
should "convert" (if necessary) to the line endings that
are normal on my machine.

I thought I was clear that this is exactly what I do not
want to happen. No matter what the client machine is, we
MUST be able to sync and submit text files in ANY format
we need no matter what kind of machine the client is hosted
on. Nothing else is acceptable since it would prevent us
from building the multiple-platform images we have to ship.
(Or at least complicate an already complex task to the point
of unacceptable risk.)

-Wm


-----Original Message-----
From: Qazwart [mailto:***@gmail.com]
Sent: Tuesday, August 14, 2007 11:56 PM

That's the reason I said "normalizing" instead of what type of file
it should be. If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings, then when a
TEXT file is checked in, whatever line endings are used, they should
be translated to the line endings that machine uses. If I checkout a
file, the line endings should "convert" (if necessary) to the line
endings that are normal on my machine.

In a source control system, all files are considered "text" unless
there is a reason to consider them otherwise. I can only think of two:
Heuristic evidence on the file suggests it is not pure text (i.e.
contains characters other than the around 90 text characters), and
the file itself is marked as a binary file.

I've used Subversion, and I know that it seems to handle the line
ending situation much better.

Post by Qazwart
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.

Nothing you stated should cause a problem (the emphasis on SHOULD).
When a file is submitted, the server should scan and replace any
necessary line endings unless the file is marked as binary. This
should happen no matter what line endings are used in your file, or
whatever line endings you client is using.

--
David Weintraub
***@weintraub.name
***@gmail.com

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Ivey, William]

Our problem really isn't with Perforce doing anything to the
line ends, it's the users who corrupt the files. Changing the
file type to binary won't fix that. The user is still free
to change the line ending by making the same mistakes they
make now (passing files from one environment to another
outside of Perforce, using a tool that converts the file
without notice, etc.).

-Wm

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Pavloff, Alex
(IE) @ SONOMAEO
Sent: Wednesday, August 15, 2007 11:51 AM
To: perforce-***@perforce.com
Subject: Re: [p4] line endings


I've got a few multi-platform issues also -- they are very sensitive to
line-endings in text files.

Easy solution? Change the filetype from "text" to "binary+D" on the
affected files.

Presto, Perforce doesn't do anything to the line-ends, but still uses
delta compression.

-Alex

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Ivey, William
Sent: Wednesday, August 15, 2007 8:16 AM
To: perforce-***@perforce.com
Subject: Re: [p4] line endings

Post by Qazwart
If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings,
then when a TEXT file is checked in, whatever line endings
are used, they should be translated to the line endings
that machine uses. If I checkout a file, the line endings
should "convert" (if necessary) to the line endings that
are normal on my machine.

I thought I was clear that this is exactly what I do not
want to happen. No matter what the client machine is, we
MUST be able to sync and submit text files in ANY format
we need no matter what kind of machine the client is hosted
on. Nothing else is acceptable since it would prevent us
from building the multiple-platform images we have to ship.
(Or at least complicate an already complex task to the point
of unacceptable risk.)

-Wm


-----Original Message-----
From: Qazwart [mailto:***@gmail.com]
Sent: Tuesday, August 14, 2007 11:56 PM

That's the reason I said "normalizing" instead of what type of file
it should be. If a file is a text file, and the normal way that the
file is stored on that system is with CR/LF line endings, then when a
TEXT file is checked in, whatever line endings are used, they should
be translated to the line endings that machine uses. If I checkout a
file, the line endings should "convert" (if necessary) to the line
endings that are normal on my machine.

In a source control system, all files are considered "text" unless
there is a reason to consider them otherwise. I can only think of two:
Heuristic evidence on the file suggests it is not pure text (i.e.
contains characters other than the around 90 text characters), and
the file itself is marked as a binary file.

I've used Subversion, and I know that it seems to handle the line
ending situation much better.

Post by Qazwart
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.

Nothing you stated should cause a problem (the emphasis on SHOULD).
When a file is submitted, the server should scan and replace any
necessary line endings unless the file is marked as binary. This
should happen no matter what line endings are used in your file, or
whatever line endings you client is using.

--
David Weintraub
***@weintraub.name
***@gmail.com

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Smith, Jeff]

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.

Jeff

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of David Weintraub
Sent: Tuesday, August 14, 2007 12:52 PM
To: G Barthelemy
Cc: perforce-***@perforce.com
Subject: Re: [p4] line endings

Post by 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).
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
***@gmail.com
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Ivey, William]

Post by G Barthelemy
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.

-Wm



-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@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
"unix" mode.