Possible downside to PQM or ChangeIntegrator?
Nicholas Allen
allen at ableton.com
Fri Oct 27 16:06:36 BST 2006
>
> 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.
>
For major features this is what we would do. But every developer also
maintains small changes/fixes on the trunk that aren't new features and
having to submit a request every time to the PQM would be a hassle in
this case. They could be given push writes to the official trunk and
then they would have to merge the trunk if necessary, before pushing.
The advantage here is that every developer's commit would not be
"wrapped" by the change integrator. The disadvantage is that we cannot
check compilation and run automated tests before allowing changes on the
official trunk which would be nice to do.
So I'm just wondering what would be the best solution for us for small
changes and fixes to trunk that are not large features or anything. The
change integrator makes this pretty easy to use without the hassle of
submitting requests to the PQM but I guess we would also need something
like the PQM functionality for merging feature branches (unless the
developer merged the feature into their trunk branch but this would then
lead to the feature being "wrapped" in 2 merge revisions which would not
be so easy to read when scanning the trunk log).
Not only that but we want to easily allow a developer to setup their own
integrator if they like so that this can be easily replicated for other
branches other than the trunk. This would allow them to be the primary
author of a given feature but to automatically integrate improvements
and fixes from other developers. The PQM is not that easy to setup per
developer. I think the change integrator would have to be a GUI
application that could be configured on the fly
(add/remove/enable/disable branches to merge from) and allow developers
to submit requests to it that would be shown in a queue list.
We need to make this as easy to use as possible for our developers.
Currently, many small changes are committed often to the trunk so this
use case would have to be a smooth one.
Cheers,
Nick
More information about the bazaar
mailing list