[MERGE] Speed up diff spec handling.

[Aaron Bentley]

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

John Arbash Meinel wrote:
> I would rather it provide a branch location than fetch. So if it can be
> (a) or (b), then I would chose (a).

If you were the one writing the code, I would cheer you on.

But this is significant scope creep, because branch locations on
RevisionSpecs are a newer interface that is frequently ignored.  I think
there are many callers who still assume that any revision-id returned is
in the context of the default branch.

Many of them would have been written before we were rigorous in our
testing, so a code audit would be required to ensure that making this
change did not introduce regressions.

I'm just trying to optimize diff.  The current behavior of
RevisionSpec_branch is buggy.  I propose to fix it in a way that is
simple, safe, and consistent with what we're already doing.  Fixing this
bug is a means to an end, so I am not trying for a perfect solution.  A
solution that is no worse than our current situation is fine with me.

To be clear about our current situation, we have regressed.  The
following commands were broken by the introduction of as_revision_id:
- - cat-revision
- - revision-info
- - inventory
- - ls
- - export
- - cat
- - merge
- - testament
- - annotate
- - merge-directive
- - send

If you're going to write the code, I'd be happy if you take the complex,
risky, revolutionary approach.  That approach would mean changing
RevisionSpec_branch so that it *never* fetches, so it would affect more
than the 11 commands I've shown.  I think that's where the greatest
rewards lie.  But I don't think it's right for you to make me do all
that so I can make a four-line change to optimize diff.

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

iD8DBQFIES0l0F+nu1YWqI0RAn1EAJ9LZ8FevVaNu8R6JZyFiQHqYLL1GQCcCnHb
wjQN+O11FEgmuXMW/xmPsrA=
=gTbX
-----END PGP SIGNATURE-----