Combining changests considered harmfull? (Re: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16)

[Andrew John Hughes]

2009/10/21 Tony Printezis <tony.printezis at sun.com>:
> Volker,
>
> Hi. I understand your point and I'm with you. The reason I pushed one
> changeset, instead of many, was not convenience (in fact, it was a bit more
> work to create the single changeset, instead of using transplant as Andrew
> pointed out, to transfer the changesets I needed). I needed to get approval
> for the push to hs16 and I was told that it was easiest to create a blanket
> CR and file one approval request. Nothing more to say.
>
> Tony
>
> Volker Simonis wrote:
>>
>> Hi Tony,
>>
>> referring to your last change I just wanted to raise the question if
>> there's a general policy in place with regard to combined changesets
>> and if combined changesets should be considered harmful?
>>
>> I understand that combining several changesets into one big changeset
>> as you did may considerably simplify the integration of changes from
>> one repository into another one. But at which prize?
>>
>> If somebody is looking at the bug description of 6888619, he won't be
>> able to see that 6888619 is fixed in hsx16. He won't even see that
>> 6888619 is related to 6893095, although the fix for 6888619 is a part
>> of the fix for 6893095. Even if somebody is just browsing hsx16, he
>> won't see at a first glance that 6888619 was fixed in hsx16, because
>> until now, the convention is that the bug ID is the first word of a
>> change description, but in the case of 6893095, the bug ID of 6888619
>> only appears in the summary field the description for 6893095.
>>
>> I already noticed this kind of slackness in hsx14.1 when the fixes for
>> the three bugs 6786503, 6787254 and 6821507 where submitted as a
>> single changeset for 6786503. This is of course worse, because here
>> there isn't even an umbrella changesets which describes which other
>> changeset it contains.
>>
>> In general I would strongly vote against such mixing and combination
>> of changesets from one repository into others even if this comes at
>> the prize of a bigger merge overhead because it makes tracking of
>> changes extremely difficult. I think Mercurial offers enough
>> possibilities for the task of transferring changesets from one
>> repository into another even if the repositories aren't related (e.g.
>> import/export or  transplant
>> (http://mercurial.selenic.com/wiki/TransplantExtension)).
>>
>> What do you think? Has this issue been discussed previously?
>>
>> Regards,
>> Volker
>>
>> On 10/21/09, antonios.printezis at sun.com <antonios.printezis at sun.com>
>> wrote:
>>
>>>
>>> Changeset: 6de2c9c36168
>>>  Author:    tonyp
>>>  Date:      2009-10-20 19:55 -0400
>>>  URL:
>>> http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168
>>>
>>>  6893095: G1: bulk G1 backports to hs16
>>>  Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041,
>>> 6887186, and 6861557.
>>>  Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov
>>>
>>>  ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentMark.hpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp
>>>  ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp
>>>  ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
>>>  ! src/share/vm/gc_implementation/g1/heapRegion.cpp
>>>  ! src/share/vm/gc_implementation/g1/heapRegion.hpp
>>>  ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
>>>
>>>
>>>
>
> --
> ---------------------------------------------------------------------
> | Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
> |                                  | MS UBUR02-311                  |
> | e-mail: tony.printezis at sun.com   | 35 Network Drive               |
> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
> ---------------------------------------------------------------------
> e-mail client: Thunderbird (Linux)
>
>
>

You can roll multiple changesets into one webrev for review, so ease
of approval isn't really an excuse either.  Seems you've been
misinformed somewhere along the line... :)
I did just that for the merging of hs14 into OpenJDK6; 554 changesets,
one webrev.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8