// The code below is correct, but can cause a lot of load on the Perforce server when we query a large number of changes because PCBs are far behind.
// If we are using zipped binaries, make sure we have every change since the last zip containing them. This is necessary for ensuring that content changes show as
// syncable in the workspace view if there have been a large number of content changes since the last code change.
if (perforceConfigSection != null && perforceConfigSection.GetValue("FindAllChangesForPCBs", false))
{
int minZippedChangeNumber = -1;
foreach (BaseArchiveChannel archive in _archives)
{
foreach (int changeNumber in archive.ChangeNumberToArchive.Keys)
{
if (changeNumber > minZippedChangeNumber && changeNumber <= oldestChangeNumber)
{
minZippedChangeNumber = changeNumber;
}
}
}
if (minZippedChangeNumber != -1 && minZippedChangeNumber < oldestChangeNumber)
{
string[] filteredPaths = depotPaths.Select(x => $"{x}[Content removed]{oldestChangeNumber - 1}").ToArray();
List<ChangesRecord> zipChanges = await perforce.GetChangesAsync(ChangesOptions.None, -1, ChangeStatus.Submitted, filteredPaths, cancellationToken);
newChanges.AddRange(zipChanges);
}
}
From PerforceMonitor.cs
- While calculating minZippedChangeNumber, this conditon “changeNumber <= oldestChangeNumber” forces the calculated value to be outside the range of the already enumerated changelists, when it could be that the current range already includes a changelist that have associated PCBs. Is that not a bug?
- This code basically looks for the highest CL in ChangeNumberToArchive across all archives, I would say that the correct algorithm would be to take the highest CL for each archive, and then take the smallest of them (to ensure that users that are using PCBs areable to sync regardless of which PCB they have selected)
[Attachment Removed]