[MERGE] Make 'missing' try the pushloc too

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew D. Fuller wrote:
> On Fri, Apr 06, 2007 at 12:32:07PM -0400 I heard the voice of
> Aaron Bentley, and lo! it spake thus:
>> I think you could make the case for running missing against the
>> parent location, push location, submit location, public location,
>> maybe even bound location.  (And personally, I think we need a
>> "merge location", too.)
>>
>> It's too much.  I think we should seriously look at an alias system
>> so you can do "bzr missing :push" or something.
> 
> This strikes me as 3 separate, if related, issues.
> 
> 1) 'missing' should do something useful if called without a location.
> 
> 2) 'missing' should be able to be run on [one/any of] the branch's
>    saved locations without having to enter the URL manually.
> 
> 3) We need location aliases.

I see a stronger connection than that.

While it's nice for 'missing' to do something if called without a
location, I think this can be pushed too far.  The counterargument is
that people expect missing to use the parent location.  If it sometimes
uses the parent location, sometimes the push location, that will be
surprising.

But if there's no push location, it should still do something, right?
What then?  Perhaps the public location is the most similar to the push
location.  And if there's no public location, then I guess we'd use the
submit location.  And if there's no submit location, I guess we'd use
the bound location.

The result is a command that is almost completely unpredictable, forcing
people to specify the location all the time, because they don't know
what will happen if they don't.

Furthermore, we could bikeshed over the order of locations all day.  I
rarely use the "push" command-- I just rsync my repositories.  So my
order of preference is:
1. parent location
2. submit location
3. public location
4. push location
5. bound location

So for someone who doesn't care about the push location, your proposal
is unhelpful.  But for someone who does, it seems inadequate.  It will
only work if the branch has no parent location.  Virtually all of my
branches have parent locations, so if I wanted to run "missing" against
the push location, I'd have to specify a full URL.

> I tend to rather prefer (2) as an option rather than as syntax, and
> (3) the other way around.

I think that doing that would make the help text much more complicated,
because commands would then take "a location or an option indicating a
location".  And because options are not positional in bzr, it wouldn't
work very well for commands that take more than one location argument.
Finally, it would be much more difficult to implement.

I'm not convinced that (3) makes sense at all.  My meaning of "location
aliases" did not include arbitrary user-configurable aliases.  If we
take care of (2) properly, there should be little need for it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGFtCj0F+nu1YWqI0RAvoYAJ4leIB+470XfsoCFrZNAUGMT/jT8ACggMO6
iJfSRdmzR2HLIuGSeH9jTE0=
=qVh5
-----END PGP SIGNATURE-----