When things go wrong

Fetch and push have a couple of failure scenarios that require action on the part of the user or shared server administrator.

Access denial

If there are permissions or authentication problems for any of the reasons outlined in the section Configure security for fetching and pushing, the fetch or push will fail with a message from the shared server. The user or shared server administrator must then address the problem before the user can attempt the fetch or push again.

History does not fit

A fetch is only allowed if the files being fetched fit cleanly into the personal server, building precisely on a shared common history. If there are any conflicts or gaps, the fetch is rejected. Otherwise, the changelists from the shared server become new submitted changelists in the personal server.

If the fetch fails, this is probably because you have attempted to fetch revisions from the shared server to your personal server that are in conflict with revisions you’ve submitted to your personal server.

“Rewriting History” explains what to do to resolve this situation.

Note

As a best practice, you should generate a report of conflicts before attempting a fetch, with the -n command-line option.

Files with filetype modifiers +k, +l or +S

Files with the filetype modifiers +k, +l, or +S require special considerations.

  • Files of type +k have their digests cleared when pushed or fetched. This means certain cross-server merge conflicts are not detected. To re-generate the digests in the target server after the push or fetch, use p4 verify.
  • When pushing or fetching files of type +l, the new files are not added to the target server if the files are currently open by a pending changelist in that server. Under these circumstances, Perforce raises an error.
  • When pushing or fetching files of type +S, old archives that exceed the specified limit are not purged by the push or fetch command.

Using triggers with fetch and push

Perforce triggers are user-written programs called by a Perforce server when certain operations are performed. You use triggers to extend or customize Perforce functionality. Triggers are of different types, depending on the event that causes the trigger to execute. Command type triggers allow some action to be taken before or after a given command.

You may use command type triggers with p4 push and p4 fetch commands. The command field of the trigger definition contains the location of the trigger and any arguments you want to pass to it. For example: 

myTrig command post-user-push "/usr/bin/perl /usr/bin/test.pl"

For more information, see "Triggering before or after commands" in the Scripting Perforce: Triggers and Daemons chapter of the Perforce Server Administrator’s Guide: Fundamentals.