RFE for webrev: the meaning of -r

[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
>>>
>>
>