As discussed on the list, we are adding an official way to keep old API around
for a short time in order to help third party developer to catch up. The
deprecated API will issue developer warning (issued by default during test runs)
to warn extensions authors that they need to upgrade their code without
instantaneously breaking tool chains and normal users.
The version is passed as an explicit argument so that developer think about it
and a potential future script can automatically check for it.
This is not build as a decorator because accessing the 'ui' instance will likely
be different each time. The message is also free form because deprecated API are
replaced in a variety of ways. I'm not super happy about the final rendering of
that message, but this is a developer oriented warning and I would like to move
forward.
We have started to isolate extra usecases for developer-only output
that is not a warning. As the section has the fairly generic name
'devel' it makes sense to tuck them there. As a result, 'all' becomes
a bit misleading so we rename it to 'all-warnings'. This will break
some developer setups but the tests are still fine and developers will
likely spot this change.
We are warning about lock acquired in the wrong order because this can create
dead-lock situation. But non-wait acquisition will not block and therefore not
create a dead-lock. So we do not need to wait in such case.
Just displaying the warning makes it quite hard to recognise the guilty code
quickly and using --traceback for all calls is not very convenient. So we
include the call site with all simple message to help developer to recognise
errors sources.
We change the wording of the developer warning:
- "lock" taken before "wlock"
+ "wlock" acquired after "lock"
The goals here are to:
- Put the "subject" as the first word,
- use "acquired" instead of "taken" since it seems more accurate.
Before this change, any call to 'wlock' after we acquired a 'lock' was issuing a
warning. This is wrong as the 'wlock' have been properly acquired before the
'lock' in a previous call.
We move the warning code to only issue such warnings when we are acquiring the
'wlock' -after- acquiring 'lock'. This is the expected behavior of this warning
from the start.
Nobody should start a transaction on an unlocked repository. If
developer warnings are enabled this will be reported. This use the
same config as bad locking order since this is closely related.
