You can have Perforce alert you about changes to sections of the depot.
To do this using the Perforce GUI.
//depot/main/.../pom.xml //depot/main/com/betweengo/foo/... //depot/proj/.../bar/...
Thanks to fellow developer Bill Crook for the tip.
Update: Michael Delaney, Perforce guru, pointed out that this works only if a P4Review daemon is running which it is not by default.
This article, Adding a Directory Tree, shows how to add a directory tree to your perforce repository.
- On UNIX, run:
find . -type f -print | p4 -x - addThe above
findcommand 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)To add symlinks, run:
find . -type l -print | p4 -x - add -t symlink- On Windows, using the MS-DOS command shell, run:
dir /b /s /a-d | p4 -x - add
Perforce branching is pretty simple.
Say you want to create a branch called
//depot/fkim/foo
First you would add it to your client.
//depot/fkim/foo/... //fkim/foo/...
Next you would do an integration from where you wanted to cut the branch.
p4 integrate //depot/work/foo/... //depot/fkim/foo/...
Then you would submit the integration and the branch will be created and updated in your client work space.
p4 submit
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:
<file> <source>src/main/scripts/foo.sh</source> <outputDirectory>bin</outputDirectory> <lineEnding>unix</lineEnding> </file>
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.
To get Perforce to work with Cygwin is not too difficult. One just has to make an alias for p4 like this (thanks to this excellent Perforce FAQ).
if [ -e /bin/cygpath ]; then alias p4='p4 -d `cygpath -w $PWD`' fi
This alias works all the time except I think when you are in a directory you accessed via a link.
Note you don’t need to go such lengths as described in this post.
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.
Another possibly simpler way is to:
Perforce has great tech notes and one of them is Perforce Reverting Submitted Changelists.
Here is how one rolls back to version N-1 .
> p4 sync …@N-1
> p4 add deleted_file
> p4 edit foo bar baz
> p4 sync …@N
> p4 resolve -ay
> p4 sync …
> p4 resolve
> p4 delete added_file
> p4 submit …
You can also do a simple rollback of a file like in this example.
> p4 sync foo#7
> p4 edit foo
> p4 sync …
> p4 resolve -ay
> p4 submit …
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.
java.lang.NoClassDefFoundError
at org.eclipse.ui.internal.themes.ThemeElementHelper.installFont(ThemeElementHelper.java:101)org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.compatibility.PluginActivator.start() of bundle com.perforce.team.ui.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
Caused by: java.lang.ExceptionInInitializerError
at com.perforce.team.ui.PerforceUIPlugin.initializeDefaultPreferences(PerforceUIPlugin.java:284)
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.
The Perforce Windows GUI has a few neat tricks.