[oe] monotone question

[Justin Patrin]

On 10/8/07, Craig Hughes <craig at gumstix.com> wrote:
> On Oct 8, 2007, at 4:10 PM, Justin Patrin wrote:
>
> > That's essentially the only way to fix it. You could also rename them
> > or move them to another place. Monotone doesn't merge these since they
> > aren't the same file ancestrally, they just happen to have the same
> > name.
>
> *sigh* OK.  It sucks that it doesn't at least give you the option of
> merging them, since identically named files in the same directory are
> more than likely related even if monotone doesn't know about it yet.
> For example, two branches both modify a package's patches in the same
> way because upstream changed...

That's called suturing and it's on the list of wanted features for monotone.

>
> >> That seems really bad cos there's a window
> >> there where the org.gumstix.oe needs to be committed in a broken
> >> state (missing those files)....
> >
> > True, but if you always expect every single revision to be bug-
> > free.....
>
> 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.

-- 
Justin Patrin