tree ec7538b096d135e3da6ef3d5d17e6a89fa192bc6
parent b4e6c902183b65b9f9d826278fc71c890d9f52e7
author Luca Milanesio <luca.milanesio@gmail.com> 1754909985 +0100
committer Luca Milanesio <luca.milanesio@gmail.com> 1754914784 +0100

Sort ref-names before locking them in filterAndLock

It is a common practise to avoid locking a set of resources in an
unpredictable order, because it would be subject to deadlocks.

Example of a possible deadlock is when two replication tasks are trying
to fetch two refs but in different order, e.g. refs/heads/branch1 and
refs/heads/branch2.

By locking the two refs in the same ordering, make sure that you never
have a situation whilst one task locks refs/heads/branch1 and the other
task locks refs/heads/branch2 and they both are stuck in trying each
other branches, when the task one tries to lock refs/heads/branch2 (lock
held by task two) and the task two tries to lock refs/heads/branch1
(lock held by task one).

Bug: Issue 437805590
Change-Id: I7fdb072e30e2313415c58e8c8dd39dd1a1f9f6e4