[patch] fix bug 30190 "'bzr cat' requires full path in old revision"

[Martin Pool]

On 16 Oct 2006, Robert Collins <robertc at robertcollins.net> wrote:
> I've reviewed this, and I have some UI concerns, as well as a bunch of
> more mechanical 'this is how we do things' requests. At the moment, I'm
> voting -1 on this.

Yes, Robert caught several important things.

> These are likely to need to be standard options and should be globally
> registered in options.py. However, I dislike the names as I think they
> are too sensitive to the context.
> For instance, I can have a tree which I have reverted to revision 50,
> and pass in -r 100. In this case, the code will consider 'old' to be
> 100, and 'new' to be the current working tree, but I might well
> internally think of 'old' as the current working tree and 'new' as
> revision 100. Lets try to find better options names here.

This is true.

The basic difference is "look up this file in the current tree and get
an old version", vs "look up the old tree and then look up this
filename."  One could call it "follow-renames", but in bzr it's not
really a matter of following renames since we go directly through ids. 
Perhaps --historic-names?

Despite that there will only be one option it should be an reversible
boolean, so you can say --no-whatever-option.

> We do have a helper that allows this to happen automatically, which I'd
> also like to see used - I see it working like this:
>  * If the user supplies --old, the file is looked up in the old tree
>  else
>  * If the file is in the current tree, it is used
>  else
>  * If the file is in the old tree it is used

The helper to which robert refers is

  Tree.find_ids_across_trees(file_list, trees)

but I'm not sure that does quite the right thing if it can't be foudn.

>  if no file is found, it is an error. This could be done easily by just
> searching for the ids in either the (current, old) trees, or the (old, )
> tree alone.

Right.

It seems like any command which takes both a filename and a -r option
will need to do something like this.  Some of them, such as diff, use -r
to get one or two revision trees plus possibly a working tree.  So in
that case I can imagine wanting to specify that the names come from one
or the other.

Suppose we are currently on r30, and foo.py has been renamed in 15 and
25:

  bzr diff -r 10..20 foo.py

The best heuristic may be to search in *all* of the working tree, 20,
and 10, but we may want to override that.

-- 
Martin