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:
- Relocates conflicting changelists to the tangent depot.
- 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:
- Run
p4 resolve
to resolve the conflict(s). - Run
p4 resubmit -Rm
to resume the resubmit.
Consider the following example:
- User A clones from a shared server, bringing down revision 4 of
//stream/main/foo.c
(//stream/main/foo.c#4
). - User A edits
foo.c
and then submits it, creating//stream/main/foo.c#5
. - 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
). - User A attempts to push their change to the shared server, but the push fails because the file version history doesn’t fit.
- 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. - User A now runs
resubmit -m
. User A’s change, originally numbered 5, is submitted as revision 7. - User A pushes their change to the shared server. The push succeeds.