monotone question

monotone question

[Craig Hughes]

I'm trying to propagate changes from the org.openembedded.dev branch  
onto my own branch, which I'd previous split off of org.oe.dev:

craig@azazel ~/code/gumstix/build/oe/org.gumstix.oe $ mtn propagate  
org.openembedded.dev org.gumstix.oe
mtn: propagating org.openembedded.dev -> org.gumstix.oe
mtn: [source] 1a130f677a5150a067c580db5a25b619d936b441
mtn: [target] 4cd685ff40e8d2ee51c4e79e8fe6545549b865b6
mtn: warning: rename target conflict: nodes 24673, 24302, both want  
parent 2139, name udev-115
mtn: warning: rename target conflict: nodes 24685, 24309, both want  
parent 2139, name udev_115.bb
mtn: warning: rename target conflict: nodes 24693, 24630, both want  
parent 25, name wifistix
mtn: warning: rename target conflict: nodes 24718, 24372, both want  
parent 23861, name gumstix-pxa270-mmc.patch
mtn: warning: rename target conflict: nodes 24719, 24373, both want  
parent 23861, name smc911x-fixup.patch
mtn: warning: resolve non-content conflicts and then try again.
mtn: error: merge failed due to unresolved conflicts

Now after some googling and head scratching, I've managed to decipher  
those errors (which call themselves warnings) mean that the left and  
right branches both added a new file with the same name.  But, how do  
I resolve this conflict in a propagate?  In a merge, I could just mv  
the file from my workdir then merge to get the file from the other  
branch, then manually merge; kind of a PITA it should just diff3 them  
for me with an empty ancestor or something and let me do the merge  
that way -- no idea why there's a special case when the ancestor is  
non-existent vs existent.  But with a propagate, there is no  
"workdir" in which to perform this.  Is the only way to resolve this  
to, say, checkout org.gumstix.oe, then delete the files from it,  
commit, then propagate?  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)....

Anyone got any thoughts on how to resolve this?

C

Re: monotone question

[Justin Patrin]

On 10/8/07, Craig Hughes <craig@gumstix.com> wrote:
> I'm trying to propagate changes from the org.openembedded.dev branch
> onto my own branch, which I'd previous split off of org.oe.dev:
>
> craig@azazel ~/code/gumstix/build/oe/org.gumstix.oe $ mtn propagate
> org.openembedded.dev org.gumstix.oe
> mtn: propagating org.openembedded.dev -> org.gumstix.oe
> mtn: [source] 1a130f677a5150a067c580db5a25b619d936b441
> mtn: [target] 4cd685ff40e8d2ee51c4e79e8fe6545549b865b6
> mtn: warning: rename target conflict: nodes 24673, 24302, both want
> parent 2139, name udev-115
> mtn: warning: rename target conflict: nodes 24685, 24309, both want
> parent 2139, name udev_115.bb
> mtn: warning: rename target conflict: nodes 24693, 24630, both want
> parent 25, name wifistix
> mtn: warning: rename target conflict: nodes 24718, 24372, both want
> parent 23861, name gumstix-pxa270-mmc.patch
> mtn: warning: rename target conflict: nodes 24719, 24373, both want
> parent 23861, name smc911x-fixup.patch
> mtn: warning: resolve non-content conflicts and then try again.
> mtn: error: merge failed due to unresolved conflicts
>
> Now after some googling and head scratching, I've managed to decipher
> those errors (which call themselves warnings) mean that the left and
> right branches both added a new file with the same name.  But, how do
> I resolve this conflict in a propagate?  In a merge, I could just mv
> the file from my workdir then merge to get the file from the other
> branch, then manually merge; kind of a PITA it should just diff3 them
> for me with an empty ancestor or something and let me do the merge
> that way -- no idea why there's a special case when the ancestor is
> non-existent vs existent.  But with a propagate, there is no
> "workdir" in which to perform this.  Is the only way to resolve this
> to, say, checkout org.gumstix.oe, then delete the files from it,
> commit, then propagate?

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.

> 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.....

>
> Anyone got any thoughts on how to resolve this?
>



-- 
Justin Patrin

Re: monotone question

[Craig Hughes]

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 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.

C

Re: monotone question

[Justin Patrin]

On 10/8/07, Craig Hughes <craig@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

Re: monotone question

[Philip Balister]

[-- 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 --]