subcommands fail when only a local import exists

Hrm, while I appreciate the difficulty here, how likely are local imports going to be?

To be clear, get_heads_and_versions can look in multiple prefixes, specified by a namespace (top-level 'directory' in refs/heads/) and a head_prefix (next-level 'directory' in refs/heads/<namespace>/).

Also, get_heads_and_versions only deals with local branches, not remote-tracking branches (as they need to be iterated differently).

I would suggest a couple of approaches, but I'm not sure what is best. Here is my initial proposal, though:

1) Restrict changes to queue code for now.

2) Given there are currently only two locations, maybe do some sort of try/except to test for the two possible ref namespaces to expect things in?

Or

1) Change queue to take a parameter that specifies the ref-namespace to look for the importer stuff? If you are doing a local import, then you would pass --import-ref-namespace=refs/headsimporter/, and it would default to refs/remotes/pkg ?

> Hrm, while I appreciate the difficulty here, how likely are local imports going to be?

I think that as long as we support local imports, we should make things work with them. For developers there's a velocity aspect too - I'd like to be able to test changes against other commands without being forced to push changes to the published branches first.

I don't remember what we agreed around the namespacing of local imports. If we don't want to fix it there, I think I favour your second option - an option to queue to tell it to use the local imported namespaces rather than the published ones.

> If we don't want to fix it there

s/fix/change/; I didn't mean to imply that it's assumed broken.