RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments

[Brent Christian]

I've been using 'webrev -N' and leaving it to webrev to determine which 
files to include based on the hg status.  I'll try giving webrev a 
filelist the next time I encounter this situation.

Thanks,
-Brent

On 1/10/13 6:50 PM, Xueming Shen wrote:
> I may not understand the real issue here, but if you list the "new" and
> "old" file
> names at the same line in the "list" file, the webrev should generate
> the diff for
> you.
>
> -Sherman
>
> On 1/10/13 11:13 AM, Brent Christian wrote:
>> Thanks, Naoto.
>>
>> AFAICT, in a case like this there where a file is moved *and* changes
>> are made to it, webrev shows that the new file is renamed from the old
>> file, but doesn't provide cdiffs/sdiffs/etc for the code changes.
>>
>> 'hg diff' behaves the same way WRT the code changes - it tells you
>> that the old file was removed and the new file was added, but you
>> don't get code diffs for the changes.
>>
>> (Interestingly, the NetBeans editor seemed to figure out what was
>> happening.)
>>
>> That's how it works for me, anyway.
>>
>> -Brent
>>
>> On 1/10/13 10:27 AM, Naoto Sato wrote:
>>> Looks good to me.
>>>
>>> BTW, I thought that webrev would effectively extract the diffs even when
>>> files were moved around.
>>>
>>> Naoto
>>>
>>> On 1/10/13 9:49 AM, Brent Christian wrote:
>>>> Hi,
>>>>
>>>> The test case for 8003228 fails in certain environments.  Also the
>>>> version that was pushed was missing a couple small changes.
>>>>
>>>> The code changes to fix these issues are here:
>>>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/
>>>>
>>>> The test case will also be moved from java/util/Properties/ to
>>>> java/lang/System/.  Webrev wouldn't do well showing that part of the
>>>> change, so it's not reflected there.  Instead I generated a webrev to
>>>> better show the code changes.
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>
>