Re: monotone question

[Philip Balister <philip@balister.org>]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

Justin Patrin wrote:
> On 10/8/07, Craig Hughes <craig@gumstix.com> wrote:
>> Bug free is not the same as broken.  You'll never be bug free, but
>> you should never be broken.  In situations where you have a build
>> tree with multiple people working on it, people throw things at you
>> hard if you ever break the build.  Big heavy things.  I guess the way
>> around this potentially in this situation would be to just create a
>> new branch off the current one, break that branch, propagate to it,
>> fix the merge issues, then propagate from that branch back to the
>> original one once everything's unbroken.  Huge pita, but it won't
>> break the build for others working on the original branch in the
>> meantime.
> 
> Well....I wouldn't consider sending 2 revs at the same time, one of
> which is broken but the newest of which is fixed breaking the
> build.... You can always put a big comment in the commit message
> saying "BREAKS THE BUILD, DO NOT USE" if you're that worried about it.
> The distributed nature of monotone does allow you to create both revs
> locally and push them both once the fixed one is done.

The model (I think) we would like to try with the gumstix people is:

Gumstix maintains a stable branch for their customer base.

Meanwhile work continues in .dev, and some of this work may involve 
files (kernel, machine etc) where changes occur in both .dev and .gumstix.

At points, the gumstix branch wants to get the changes from .dev. There 
will be some files that contain fixes, but the exact fix may be 
different in each branch. As part of the propagate from .dev to 
.gumstix, the .gumstix branch maintainer should have an opportunity to 
review these differences and decide what goes into .gumstix.

Philip


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]