[p4] Rollback-Like behavior on Submitted files

P4Sam perforce-user-forum at forums.perforce.com
Thu May 28 11:00:01 PDT 2015

Posted on behalf of forum user 'P4Sam'.

There aren't any obvious clues in the file history, but the simplest way for
an "accidental" rollback to happen would be as follows (you might need
to talk to Killbot and see if this sounds like a possible sequence of events):

1) File is synced to an older revision (or file is synced to head before changes
are submitted from another workspace).
2) File is checked out and modified (or not).
3) File is either submitted or synced.  This will schedule a resolve.
4) File is resolved with the "accept yours" option.  (This
is important -- the user needs to explicitly choose "accept yours" to
discard "their" changes.)
5) File is submitted.

The point at which the newer changes are discarded is step 4, where the user
does the required "resolve" and opts to ignore the newer
changes.  With a text file you'd handle this by doing a
"merge"; with an unmergeable binary file this isn't an option,
which would explain why users are doing "accept yours" instead (even
though this means losing the other users' changes).

To prevent this situation there are two things you can do:
1) Make sure to "get latest" on files before checking them
out.  You're probably already doing this, since Perforce will warn
you about checking out files that aren't already up to date in the
workspace, and I think P4V will even prompt you to sync them prior to checking
them out.
2) Don't edit binary files concurrently.  Again, Perforce will
warn you when you're checking out a file that someone else has already
checked out, but users might be ignoring this.  You can force the
issue by changing the file type to "binary+l", which forces exclusive
checkouts -- once one user checks out a file, everyone else is blocked from
checking it out until they either revert or submit.

Please click here to see the post in its original format:

More information about the perforce-user mailing list