The lock listing produced by "ael l" gives somewhat creative output, due to the algorithm used to reverse the project name hash and guess change numbers.
As noted in the code:
This is very messy, because the change
number is added to the project name hash.
[...] We could do better by looking in each
project, but what the hell.
I am attaching a patch (to Aegis 4.22.2) that searches for candidate project/change pairs matching the hash until it finds one that corresponds to an actual project and change. It's not perfect (for instance, there could be more than one project/change pair that matches the hash) but at least for our set of projects, it produces more useful output than the current implementation.
Malcolm Butler
improved "list locks" output