Resolve conflicts by rewriting local history

If there are conflicts between a personal server’s file history and a shared server’s file history, a fetch will fail and report the conflict. This happens when you’ve changed some files in your personal server at the same time that someone else has changed those files in the shared server.

In this situation, you run p4 fetch -t. This does the following:

  1. Relocates conflicting changelists to the tangent depot.
  2. Fetches the remote work from the shared server.

You then run p4 resubmit -m to resubmit and automatically merge the conflicting local changes.

If your conflict(s) involved the same line or lines then p4 resubmit -m fails and you need to:

  1. Run p4 resolve to resolve the conflict(s).
  2. Run p4 resubmit -Rm to resume the resubmit.

Consider the following example:

  1. User A clones from a shared server, bringing down revision 4 of //stream/main/foo.c (//stream/main/foo.c#4).
  2. User A edits foo.c and then submits it, creating //stream/main/foo.c#5.
  3. In the meantime, User B, has made two edits to //stream/main/foo.c and pushed them to the shared server. The shared server is now at revision 6 (//stream/main/foo.c#6).
  4. User A attempts to push their change to the shared server, but the push fails because the file version history doesn’t fit.
  5. User A must now run fetch -t, which relocates User A’s revision 5 to the tangent depot, and fetches revisions 5 and 6 from the shared server.
  6. User A now runs resubmit -m. User A’s change, originally numbered 5, is submitted as revision 7.
  7. User A pushes their change to the shared server. The push succeeds.