Bug Fixes
#815374 (Bug #71661) ** 'p4 reconcile -n will no longer take an exclusive lock. In a distributed environment this could cause orphaned exclusive locks. This has been fixed.
#811622 (Bug #71819) ** 'p4d -xf 71819' may now be used to clear invalid or unnecessary charset values from the database. Note that this will scan the entire revision table.
#811455 (Bug #71765) ** 'p4 reopen' will no longer set a charset on a non-Unicode file.
#799439 (Bug #71686) ** 'Accept theirs' charset resolves from revisions with corrupt charset values will no longer cause a crash.
#798198 (Bug #71648) ** A case in which a file with multiple sequential deleted revisions could require integration unnecessarily has been fixed.
#782068 (Bug #71155) ** 'p4d -xx db.working db.have' could create spurious delete records for db.working if a file opened for edit is subsequently moved and submitted by another client and the opened file is then synced to the head revision.
#781820 (Bug #70845, #70906) ** Some merge cases involving files being moved, deleted, and readded in unusual ways are now handled better.
#778881 (Bug #70696) ** With 'db.peeking' enabled in 2013.3, long running (overlapping) 'p4 sync' operations would block 'p4 obliterate' from running.
#778845 (Bug #70908) ** Disabling the db.peeking level and then running 'p4 admin restart' would not change the lock order back correctly, resulting in lock order errors.
#778057 (Bug #70962) ** A 'sync -s' or client with the 'allwrite' option during a sync can cause a Server fault if max results is hit. This has been corrected.
#777796 (Bug #70950) ** A 'p4 revert' command which ran concurrently while a 'p4 shelve' command was underway using the same workspace and changelist could cause that shelve command to crash, if the shelve command included certain undocumented arguments.
#773134 (Bug #70702) ** With 'peeking' enabled and a very high submit concurrency rate, the maxCommitChange counter may get updated in the wrong order. This bug might cause some transient inconsistency (most likely with aggressive automation that tracks submits).
#772545 (Bug #70700) ** A long running connection that switches between task and non-task streams could run into lock order issues when issuing a submit. The error "Locking failure: db.revtx locked after db.revdx!" would be observed on submit. A subsequent attempt to submit the change would result in success.