post 0.8 development

[John A Meinel]

Jan Hudec wrote:
> On Mon, May 08, 2006 at 12:44:09 -0700, John A Meinel wrote:
>> Matthieu Moy wrote:
>>> * there's also my old "how to get the diff between two remote 
>>> revisions", but nobody seems interested, so I'll have to do it myself 
>>> when I have time ;-).
>> There is a bug report for "bzr diff -r 1..2 http://path/to/branch" not 
>> working. And I do think we are interested in fixing that one. (I am, at 
>> least). I looked into it, but the cmd_diff code is a little tricky, 
>> because it does a lot of different things based on what the arguments 
>> are. (If it is 2 branches it does something different than 2 files, 
>> different from no files, etc).
> 
> What is 'bzr diff -r 1..2 http://path/to/branch supposed to do?
> - Diff revision 1 of http://path/to/branch against revision 2 thereof

This is what it already does, but only if path/to/branch is local. 
(Because it requires a working tree).

The change is only to allow diff to work when there is no Working Tree, 
but two revisions are given.

> - Diff revision 1 of . against revision 2 of http://path/to/branch
> - Diff revision 1 of http://path/to/branch against revision 2 of .
> Guess reading --help would tell me, but it takes a hack lot thinking each
> time I need to use it. The ;revision notation would really help here:
>   bzr diff .;revno=1 http://path/to/branch;revno=2
> can't be confused.
> Note that it is longer, so it should not replace -r completely. Though one
> could write:
>   bzr diff http://path/to/branch;revno=1 http://path/to/branch;revno=2
> with a bit of shell magic as:
>   bzr diff http://path/to/branch;revno={1,2}

Except the shell would interpret that as:
bzr diff http://path/to/branch
revno=1 revno=2

Which would do something *very* different. (One of the reasons we were 
discussing using something other than ';' as the parameter specifier. 
',' is the alternative, but it might be too common in a filename)

> 
>> I don't think we've settled down on our URL scheme to support
>> http://path/to/branch;revision=foo
>> But I think if someone actually implemented a parser for that, we would 
>> consider merging it. (The one who actually implements it will get a lot 
>> of say as to how the syntax will actually work).
> 

John
=:->