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

[Andrew John Hughes]

2009/10/21 Volker Simonis <volker.simonis at gmail.com>:
> 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
>>
>>
>

Hi Volker,

I just saw this changeset too and was about to comment as well.  I
agree wholeheartedly with what you're saying.  It's pretty trivial to
transplant changesets with Mercurial; hg export <changeset id>| hg
import - will do the job, and the transplant extension makes it
simpler still.  I do this regularly with JDK7->JDK6,
IcedTea6->IcedTea7, etc.  This bulk commit seems more trouble to be
honest, as you have to allocate another bug ID for it, whereas porting
the patches individually would just use the same ID per patch!
-- 
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