RFE for webrev: the meaning of -r

[weijun.wang]

Hi Jessie

Currently, 'webrev -N -r n' creates a diff from rev n to the working  
directory. Is this really useful? How about output a diff for the  
changeset rev=n itself?

Working on multiple bugs at the moment, I would be very glad to call  
'webrev -N -r n' with n=-1,-2,-3... to output a series of webrevs for  
each changeset I just made.

Thanks
Max

[John Rose-6]

On Feb 23, 2009, at 7:10 PM, Max (Weijun) Wang wrote:

> Currently, 'webrev -N -r n' creates a diff from rev n to the working  
> directory. Is this really useful? How about output a diff for the  
> changeset rev=n itself?

It's useful if people don't want to commit their changes before  
reviewing.  (Actually, I use mq to manage my changes, and it does  
pseudo-commits.)

> Working on multiple bugs at the moment, I would be very glad to call  
> 'webrev -N -r n' with n=-1,-2,-3... to output a series of webrevs  
> for each changeset I just made.

The mercurial way to say this sort of thing is 123:124, where the  
numbers name two revisions.  Perhaps that can be integrated into  
webrev, although it would touch a couple dozen lines.

Best,
-- John

[weijun.wang]

On Feb 24, 2009, at 12:51 PM, John Rose wrote:

> On Feb 23, 2009, at 7:10 PM, Max (Weijun) Wang wrote:
>
>> Currently, 'webrev -N -r n' creates a diff from rev n to the  
>> working directory. Is this really useful? How about output a diff  
>> for the changeset rev=n itself?
>
> It's useful if people don't want to commit their changes before  
> reviewing.

'-N' itself is useful, but I cannot see what the benefit '-N -r n' is.  
Wrapping several changes into a single webrev?

>  (Actually, I use mq to manage my changes, and it does pseudo-
> commits.)

Me too. I qgoto a patch and call 'webrev -N -r -2' to create a webrev  
now.

>
>
>> Working on multiple bugs at the moment, I would be very glad to  
>> call 'webrev -N -r n' with n=-1,-2,-3... to output a series of  
>> webrevs for each changeset I just made.
>
> The mercurial way to say this sort of thing is 123:124, where the  
> numbers name two revisions.

This looks better.

Thanks
Max

>  Perhaps that can be integrated into webrev, although it would touch  
> a couple dozen lines.
>
> Best,
> -- John

[John Rose-6]

On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:

> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a  
> webrev now.

Well, that's about what I do, except I have it merge up all my queued  
changes sometimes.

I sometimes have used a wrapper script which finds base revision of  
the queue like this:

> diffbase=$(hg log --rev qparent --template '{rev}')
> ...
> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...

Saying "webrev -N -r qbase:qtip" could make sense...

-- John

[Jean-Christophe Collet]

I'll see what I can do
In the meantime may I suggest you give jHg a try
(http://sunweb.swiss/~jccollet/jHg/ )
It's a java tool I wrote that is much more flexible than the webrev script.
I'm actually considering building a NetBeans module based on it.

John Rose wrote:

> On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:
>
>> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a webrev
>> now.
>
> Well, that's about what I do, except I have it merge up all my queued
> changes sometimes.
>
> I sometimes have used a wrapper script which finds base revision of
> the queue like this:
>
>> diffbase=$(hg log --rev qparent --template '{rev}')
>> ...
>> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...
>
> Saying "webrev -N -r qbase:qtip" could make sense...
>
> -- John

[jonathan.gibbons]

Neat looking tool.

Would it be too much of  a stretch to have the tool optionally publish  
the webrev to a remote location
such as the new code review server?

-- Jon

On Feb 24, 2009, at 6:57 AM, Jean-Christophe Collet wrote:

> I'll see what I can do
> In the meantime may I suggest you give jHg a try (http://sunweb.swiss/~jccollet/jHg/ 
>  )
> It's a java tool I wrote that is much more flexible than the webrev  
> script.
> I'm actually considering building a NetBeans module based on it.
>
> John Rose wrote:
>> On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:
>>
>>> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a  
>>> webrev now.
>>
>> Well, that's about what I do, except I have it merge up all my  
>> queued changes sometimes.
>>
>> I sometimes have used a wrapper script which finds base revision of  
>> the queue like this:
>>
>>> diffbase=$(hg log --rev qparent --template '{rev}')
>>> ...
>>> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...
>>
>> Saying "webrev -N -r qbase:qtip" could make sense...
>>
>> -- John
>

[Jean-Christophe Collet]

Jonathan Gibbons wrote:
> Neat looking tool.
>
> Would it be too much of  a stretch to have the tool optionally publish
> the webrev to a remote location
> such as the new code review server?
>

Good point. I'll try to do that as soon as I get some time

> -- Jon
>
> On Feb 24, 2009, at 6:57 AM, Jean-Christophe Collet wrote:
>
>> I'll see what I can do
>> In the meantime may I suggest you give jHg a try
>> (http://sunweb.swiss/~jccollet/jHg/ )
>> It's a java tool I wrote that is much more flexible than the webrev
>> script.
>> I'm actually considering building a NetBeans module based on it.
>>
>> John Rose wrote:
>>> On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:
>>>
>>>> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a
>>>> webrev now.
>>>
>>> Well, that's about what I do, except I have it merge up all my
>>> queued changes sometimes.
>>>
>>> I sometimes have used a wrapper script which finds base revision of
>>> the queue like this:
>>>
>>>> diffbase=$(hg log --rev qparent --template '{rev}')
>>>> ...
>>>> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...
>>>
>>> Saying "webrev -N -r qbase:qtip" could make sense...
>>>
>>> -- John
>>
>

[jonathan.gibbons]

It would be nice to decouple as much as possible the back end of how to
publish the webrev.
For example, perhaps the tool could collect basic information such as
the bug ID, a description
of the change, and the location of the webrev directory, and hand this
info off to a back-end
script provided by the user.  That way we could easily use scripts to
write files out to the
code review server, to the sa.sfbay server, or any other systems that
might come along in
future.

-- Jon

Jean-Christophe Collet wrote:

> Jonathan Gibbons wrote:
>> Neat looking tool.
>>
>> Would it be too much of  a stretch to have the tool optionally
>> publish the webrev to a remote location
>> such as the new code review server?
>>
>
> Good point. I'll try to do that as soon as I get some time
>
>> -- Jon
>>
>> On Feb 24, 2009, at 6:57 AM, Jean-Christophe Collet wrote:
>>
>>> I'll see what I can do
>>> In the meantime may I suggest you give jHg a try
>>> (http://sunweb.swiss/~jccollet/jHg/ )
>>> It's a java tool I wrote that is much more flexible than the webrev
>>> script.
>>> I'm actually considering building a NetBeans module based on it.
>>>
>>> John Rose wrote:
>>>> On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:
>>>>
>>>>> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a
>>>>> webrev now.
>>>>
>>>> Well, that's about what I do, except I have it merge up all my
>>>> queued changes sometimes.
>>>>
>>>> I sometimes have used a wrapper script which finds base revision of
>>>> the queue like this:
>>>>
>>>>> diffbase=$(hg log --rev qparent --template '{rev}')
>>>>> ...
>>>>> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...
>>>>
>>>> Saying "webrev -N -r qbase:qtip" could make sense...
>>>>
>>>> -- John
>>>
>>
>

[Kelly O'Hair]

And don't forget that button that submits the patch to a build system that
verifies the patch works on all platforms and also runs all smoke tests.... ;^)

Oh dear, I think I'm supposed to do that... nevermind.... ;^>
Now if I can just figure out how my Sunbeam toaster does it....

-kto

Jonathan Gibbons wrote:

> It would be nice to decouple as much as possible the back end of how to
> publish the webrev.
> For example, perhaps the tool could collect basic information such as
> the bug ID, a description
> of the change, and the location of the webrev directory, and hand this
> info off to a back-end
> script provided by the user.  That way we could easily use scripts to
> write files out to the
> code review server, to the sa.sfbay server, or any other systems that
> might come along in
> future.
>
> -- Jon
>
> Jean-Christophe Collet wrote:
>> Jonathan Gibbons wrote:
>>> Neat looking tool.
>>>
>>> Would it be too much of  a stretch to have the tool optionally
>>> publish the webrev to a remote location
>>> such as the new code review server?
>>>
>>
>> Good point. I'll try to do that as soon as I get some time
>>
>>> -- Jon
>>>
>>> On Feb 24, 2009, at 6:57 AM, Jean-Christophe Collet wrote:
>>>
>>>> I'll see what I can do
>>>> In the meantime may I suggest you give jHg a try
>>>> (http://sunweb.swiss/~jccollet/jHg/ )
>>>> It's a java tool I wrote that is much more flexible than the webrev
>>>> script.
>>>> I'm actually considering building a NetBeans module based on it.
>>>>
>>>> John Rose wrote:
>>>>> On Feb 23, 2009, at 8:56 PM, Max (Weijun) Wang wrote:
>>>>>
>>>>>> Me too. I qgoto a patch and call 'webrev -N -r -2' to create a
>>>>>> webrev now.
>>>>>
>>>>> Well, that's about what I do, except I have it merge up all my
>>>>> queued changes sometimes.
>>>>>
>>>>> I sometimes have used a wrapper script which finds base revision of
>>>>> the queue like this:
>>>>>
>>>>>> diffbase=$(hg log --rev qparent --template '{rev}')
>>>>>> ...
>>>>>> webrev -m -N -i $info -o $temp -r $diffbase -p "$parent" ...
>>>>>
>>>>> Saying "webrev -N -r qbase:qtip" could make sense...
>>>>>
>>>>> -- John
>>>>
>>>
>>
>