When we perform a database upgrade, we try to build up a map of any

repositories that need to be updated. We try to be careful, selecting

only the specific repository fields we need and deferring the rest, in

particular, scmtool_id, because that field may not exist during the

upgrade process.
Unfortunately, my addition of a signal handler to lazily upgrade

repositories that couldn't be migrated at this stage (due to uninstalled

extensions and such) broke this. It would attempt to access

scmtool_id, which would cause a database query to fetch that value,

breaking when the evolution hadn't yet been applied.
This change avoids any scmtool_id migration attempts if working with a

repository containing any deferred fields.
In a way, this is a bandaid. A better solution may be to have state that

says "we're doing upgrade operations, please hold" and allow code to

check that. But that'll come later.
In the meantime, this is still a good fix to keep around, as it avoids

extra database queries that may not be wanted.

All unit tests pass.
Tested this in production when hitting this problem during the upgrade

process, which broke due to the field query. This fix allowed the upgrade

to take place.