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

[Tony Printezis]

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)