Possible downside to PQM or ChangeIntegrator?

[Erik Bågfors]

On 10/27/06, Nicholas Allen <allen at ableton.com> wrote:
> Hi,
>
> After thinking a bit more about the change integrator and how it would
> work I can see a few problems with this approach. We would like to
> compile and run automated tests by the change integrator before pushing
> to the official trunk version. When it merges in a developer's branch
> this will happen at some undetermined time and all the changes made to
> the developer`s branch may not all be related and therefore should not
> be merged as one commit. I know bzr can distinguish between the sub
> revisions of the merge but it would be nice that all commits to the
> trunk had one single related purpose.
>
> Using PQM developers would submit requests to merge their branch up to
> the head revision at the time the request is made. So even if PQM merges
> it 2 days later it will not include revisions that were made after this.
>
> But this also brings up a possible problem with PQM. If it decides that
> it will not merge a request from a developer (eg does not compile) it
> then informs the developer but what if the developer has already made
> unrelated changes in his branch by this time? He can submit another
> merge request for his branch but now the unrelated changes will get
> merged with the original changes. The only other thing he could do is to
> make another branch at the revision that originally wanted to be merged,
> fix the problems reported by the ChangeIntegrator or PQM, and then
> submit a merge request for this new branch. But how would he also
> separate out the new changes he made in his original branch if he wanted
> to submit these first?
>
> The only other solution is to require that each developer creates a
> separate branch all the time and all commits on a branch must be for a
> related reason. But there are often many small commits by a developer
> and this would be cumbersome.
>
> So the question boils down to how do you fix changes reported by the PQM
> and then request a new merge but still continue to work in your branch
> while the request is being processed?
>
> Can anyone shed any light on this after using PQM for a while?


What people are doing today with PQM is doing different features in
different branches, and therefore this is not a problem. This is the
way I would recommend doing it.

That way, you might change the change integrator to look for branches
from a given developer under a certain directory, and then merge all
of them.

The only other solution I can see, is when we have tags in bzr.  What
you could do then is to merge up to a tag at each time.  This would
mean that a developer would have a "tag for merge" operation instead.
But if the change integrator would find a branch with many tags, it
would merge up to the first tag, commit that, then merge to the second
tag, etc.

I don't know exactly how to deal with the situation where you might
have errors in the "set" (up to the first tag) in this case, but I
assume something like this would be needed

bzr branch -rtag:tag1 mybranch newbranch
cd newbranch
fix problem; commit
bzr tag --move tag1 (or whatever the tag-command will be)
bzr merge ../mybranch
bzr ci -m 'merge'
bzr push --overwrite ../mybranch;
cd ../mybranch
bzr push

That way, the tag1 "set" will come first, and the tag2 "set" will come after....

/Erik