The above find command will find files, but will not find symlinks. Nevertheless, you can add symlinks to Perforce using a similar method. Be aware, however, that symlinks are read-only entites, and that editing a symlink is not the same as editing the file it references.
To discover the symlinks that exist in your client workspace and assess whether or not you want to version them, run the following command from your client workspace root:
find . -type l -print
(That's an "el" as in "l" for link)
In a previous post, Shell Scripts with Windows LF’s Fail in Latest Cygwin, I wrote about how to use Perforce to check out all files in UNIX format. However if you use Eclipse then this solution will not work because Eclipse always inserts Windows LF’s in any line you insert into a file leading to a mess with files that have both UNIX and Windows LF’s.
However if you happen to use Maven to generate / copy your shell scripts to their target directories you can take advantage of the lineEnding property in the Assembly Director. If you specify the lineEnding property to be “unix” then the outputted shell scripts will be in UNIX format. For example:
I am not sure when this happened but now in Cygwin shell scripts with Windows LF’s (the infamous control M’s) fail, i.e. Cygwin fails to run them because it will complain about the ‘\r’ character.
The simple way to fix this is to change your scripts to use UNIX LF’s by calling dos2unix or “conv -U”.
If you are using Perforce on Windows and seeing this problem then you can change your client to use “share” for the LineEnd option. Since Perforce stores all its text files in UNIX format on the server then it will write them out locally on your Windows machine in UNIX format. See the Perforce Knowledge Base article, CR/LF Issues and Text Line-endings. Fortunately Windows batch scripts with UNIX LF’s still run properly.
Note that when you make this change from the “local” LineEnd option then text files you already checked out will have the Windows LF’s. You will need to do a p4 sync -f on the files you want updated to have UNIX LF’s. Also when do you a p4 diff on your opened text files it will look like the whole file has changed. Again this is because of line feed issues. Doing a dos2unix on those opened text files will solve the problem.
Since I am no longer using Perforce I wanted to turn off the Windows Explorer because somethings I would accidentally select the Perforce option in the right click menu and it would hang for a long time as it tried to reach the Perforce server.
This blog article says that the simplest way to do this is to select Change/Remove Perforce P4Win Components from the Add or Remove Programs Control Panel and then select the Windows Explorer integration for uninstall. When it is done uninstalling a reboot is required.
My laptop unexpectedly shutdown when I had Eclipse open. After rebooting I could not start Eclipse. Instead it kept crashing with the message “An error has occurred. See the log file …” Looking at the log file I saw errors related to the Perforce plugin.
org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.start() of bundle com.perforce.team.ui.
Caused by: java.lang.ExceptionInInitializerError
I saw a post about this problem which referred to another post for a solution. Basically the post suggests that stale plugin cache information is causing the problem and suggests starting Eclipse with the -clean argument. After doing this I was successfully able to launch Eclipse.
If you click on a folder/file in the depot view of the Perforce Windows GUI and do a copy (Ctrl+C), then if you do a paste in another application it will paste the complete depot path to that folder/file.
If you copy the Windows path to a folder/file in your work space and then do a paste in the depot view the Perforce Windows GUI will reveal where in the depot the folder/file is located.