Is there a way to tell Perforce to leave text files alone without setting the file-type as binary? Or barring that, is there a way to tell the Perforce client to diff binaries? Binary usually isn't desirable, because I lose the ability to diff.
To clarify: If I edit and make changes to a *.txt file on my window client, newlines will have CR+LF as per the DOS format. But if I P4 sync on a Unix client, it will have LF only. I need Perforce to keep the format as-is, regardless of where the Perforce client lives.
That said, I do have a work-around: Set file-type as binary; and/or create a branch with text files set as "text", and integrate periodically back into the mainline where text files are set as "binary". But this is an overly-complicated work-around for what should be a very simple problem.
Finally, I'm on Perforce Windows client 2006.2.
Thanks in advance.
Set all of your client/workspace specs to 'unix' line-endings. Then no conversion will take place when you check in on Windows.
See http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/
The Perforce client can handle line ending properly when syncing to different platforms provided you have LineEnd option set properly on your client. Perhaps you have yours set wrong? Open up your client specs and set the LineEnd option according to your needs.
Check out this KB article on their website for more info. Here's an excerpt:
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 p4 sync, p4
submit and p4 diff.
On the client workspace side, Perforce
handling of line-endings is determined
by a global option for each
clientspec. When you sync text files
to a client workspace with p4 sync, or
submit them back to a Perforce Server
with p4 submit, their line-endings are
converted as specified in the
clientspec LineEnd section.
When adding text files that you want to be considered binary to Perforce, use the command p4 add with the -t option to override the type mapping table. See the documentation here. The example given there is p4 add -t binary file.pdf.
I have just come across exactly the same problem, but have a better solution that does not involve changing client specs (which are international, and not all of which I have write access to).
All of our clients are Windows PCs, but Cygwin is included within the Perforce Depot. Cygwin is a Windows implementation of Unix, and requires that text files use LF for line endings.
A possible solution for older versions of Cygwin is to mount the root using the "text" option, meaning that files can have CR+LF line endings. However, on upgrading to Cygwin 1.7.9, this no longer worked, as mounts are transient unless they are written into /etc/fstab. I did not manage to make this work.
Luckily, the Perforce Guru sitting next to me came up with the solution of changing the filetype to binary+D, which uses the same RCS incremental patch storage as text files, but without the automatic line ending conversion.
I can diff these "text" files successfully between my local workspace and the depot.
Give the files a different extension.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
I'm on a Windows machine, and in my P4V workspace:advanced-settings, I have the following selected:
But I still notice extra spaces in some of my files after submitting and checking on a different machine. Is there a way to force every checkout and submission to be Unix style?
Note, I can't modify server settings, only my local workspaces.
If you set the LineEnd to unix and the files you sync have \r characters in them, it means that somebody using unix submitted them in that form (i.e. the files were checked in with the understanding that the Unix version of them is supposed to have those characters in there distinct from the native line endings). If you submit Windows-style files from a unix-mode workspace, you're saying that all unix workspaces should have Windows-style line endings for those files. This is desirable in some instances, like when you're using Unix machines to build packages for Windows systems, but for source code that's meant to be used cross-platform it's generally a bad thing.
It's not too hard to go through the history, figure out who did that, and cluebat them (or get the admin to force a fix of their LineEnd setting so that it actually matches the contents of their workspace), and I wholeheartedly recommend doing this any time you ask for unix files and get a win-style file that you didn't want. Usually if everyone uses the default setting of local everything works fine.
As far as fixing the files, a pretty easy method is to change your LineEnd to share, open all the files for edit, and then submit them -- the share setting forces all the \r characters to be stripped out on submit, as if you were running dos2unix over all your files every time you submitted.
I had a project on Mac and uploaded it to a perforce server. When I got the project from PC all the line endings were changed and now it does not compile on PC. Is there a way to automatically change the line endings like they were before or I must submit again all the project from Windows? Is there any way to make perforce to keep my files AS THEY ARE? I really don't want to have stupid modifications in my source files.
Thanks!
EDIT:
It has to do with perforce, I just edited 10-20 files on MAC to make a multiplatform project to compile. The rest of 140k files were not changed and not even opened on Mac(they were opened by compiler to compile them:P). If I copy the project on PC the line endings are ok.
Line endings for text files are controlled by your client spec setting. You need to make sure that your client's 'LineEnd' value is set properly. In general, this should be left to 'local' which should do the right thing for whatever operating system you are using.
That said, depending on how this value was set on your Mac when you originally uploaded the files, I suppose that there could possibly be some problem when syncing those files to your PC.
I would check to make sure that LineEnd is set to 'local' for your clients. There is a note on the Perforce Knowledge Base site here that talks more in depth about proper settings for Macintosh clients. That might be a place to start as well to make sure that you have things properly configured on your Macintosh.
Yes you can. Using Unix line-endings for both your clients will tell the perforce clients to leave the files unchanged from how they were submitted. You can also setup a trigger on the server to force it this way, refer to my answer to this question:
Setting Perforce line endings
This doesn't have anything to do with perforce really, although it does handle the problem.
http://kb.perforce.com/article/63
Line endings on UNIX, PC and Mac machines are all different. This is what your seeing. Transferring the same file between PC and Mac over any medium would have the same results. You can probably set your editor on the Mac to save the file with windows line endings if you want to get around this another way.
I was wrong "Perforce processes all text files using Unix-style LF line-endings". I'd check p4 client LineEnd value (should be local on both machines I think) and ensure you're using a version of p4 >= 2001.1
Suppose you open a file for branch to another place (without submitting), and then reopen it for add and make some edits. I would like to diff this edited version against its branch source in a script.
p4 diff2 is no good because one of the versions is in the client.
p4 diff is no good because it can only diff against the "corresponding" version of the file in the depot, which a branched unsubmitted file doesn't have yet.
Is there a way, or is the only option to just grab the two files and diff them using a third-party tool?
Sadly, you're on the money here, you'd need to use a third party diff tool to do this because, as you rightly pointed out, until you've submitted the initial integration to the depot, it doesn't have a copy against which to diff. If you go down this route you'd obviously not be able to access files directly in the depot though, you'd need to have both files on the client PC and specify their paths explicity.
ninesided is correct that you need to have both files on the client PC.
But there are shortcuts:
If you're using P4V, choose "Diff Against..." from the context or Tools menu. For 1st Path, choose the old location and select "Latest Revision'. For 2nd path, choose the new location and select "Workspace revision on local disk".
The work of selecting the paths can be made easier if you can get both files to appear in the same pane and Ctrl-click to multi-select. e.g. use the Workspace tree pane or open the source file for edit temporarily in order to get it listed in the Pending files pane.
P4V accomplishes this by running 'p4 print -o' on the depot file to create a temporary file on the client PC, then passing that temporary file to the diff application. If you need a textual diff, you can either configure P4V to run a textual diffing application, or run p4 print -o and diff yourself.
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.