Possible downside to PQM or ChangeIntegrator?

[John Arbash Meinel]

Nicholas Allen wrote:
> I just thought of a way the change integrator could work in this
> situation. If it always merged each revision from the developer's branch
> as a separate revision into the trunk but only ran the compilation stage
> after all revisions had been separately merged and only pushed to the
> official trunk if all changes as a whole compiled. This could mean that
> individual commits on the trunk may not compile but by the time they
> make it onto the official trunk as a whole they would.
> 
> This would mean that every commit a developer made to his trunk would be
> represented by one merged commit on the official trunk.
> 
> It would be nice if every commit on the trunk was not "wrapped" in a
> commit by the change integrator. Since the change integrator commit
> would wrap one commit by one developer it would be nice if that
> developer's commit just appeared on the official trunk with no mention
> of the change integrator. But I guess this would not be possible would it?
> 
> Cheers,
> 
> Nicholas Allen
> 
> 

It would be possible if the developer's branch was always a superset of
the trunk. But the whole point is that you have N developers, so all of
them cannot be a superset of all others at any given moment. :)

Now, you could graft things onto the mainline. Meaning you do a merge of
each one, but throw away the parent link. Which means you get new
revisions, but you wouldn't see them all as merges of something else.
Meaning instead of:

  v- trunk
    v- developer 1
  A
  |\
  B C
  |/|
  D E
  |/|
  F G
  |/|
  H I
  |/
  J

You could see:
  A
  |\
  B |
  | |
  D C
  | |
  F E
  | |
  H G
  | |
  J I

Where they all have the same commit information (committer, effective
change, etc) but you don't have the ancestry links, which means that
commits C E G I are effectively just ignored after this point.

Another possibility would be to make it turn into:

  A
  |\
  B C
  | |
  D E
  | |
  F G
  | |
  H I
  |/
  J

So you have the individual commits, but only a single merge commit.

Personally, I think:

  A
  |\
  B C
  | |
  | E
  | |
  | G
  | |
  | I
  |/
  J

Really is the best way to go. Because then your mainline becomes
something like:

[merge] Add feature bar
    Create function foobar
    fix function foobar
    use foobar in function baz
    fix edge case in baz
[merge] Add feature foo


This leaves you with the ability to find the details of any given small
change. But leaves your main history nice and clean about what things
are finished at what time.

Which is why I like the PQM workflow over the ChangeIntegrator one. I'll
respond more to your other message later.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061027/4a225876/attachment.pgp