Re: A question of workflow

[Patrick Ohly <Patrick.Ohly@gmx.de>]

On Mon, 2007-01-08 at 11:11 -0800, Justin Patrin wrote:
> On 1/8/07, Patrick Ohly <Patrick.Ohly@gmx.de> wrote:
> > On Sun, 2007-01-07 at 14:46 -0800, Justin Patrin wrote:
> > > One thing I could see us doing is possibly comitting a patch as-is and
> > > then making changes and comitting that. (Of course, we wouldn't push
> > > until it's all finished) but I don't know how well that will merge.
> >
> > I think it would merge as well (or bad) as committing to a branch first.
> > The reason why I didn't mention this possibility is that it means that
> > the core developer's revision of the trunk gets temporarily "polluted"
> > with an unchecked and possibly incomplete patch. That might prevent
> > finishing and pushing some other, more important work. I also don't know
> > how easy it would be to back out the patch completely.
> 
> I'm not sure what making another branch realy buys here.

The main point which makes life easier for external contributors is that
the patch is applied as-is and then modified, with all changes recorded
in monotone. However, you are right: the change must be recorded on
trunk. Making it on a branch and then only propagating the result fails,
see below.

>  In fact, I'm
> not even sure how monotone is happily merging your conflicts seeing as
> the patch would still be coming from 2 places.

I don't know exactly why it worked, but it did in a case where the
normal "reapply your patches" method would have failed.

I also tested another scenario that we have mentioned:
      * the contributor creates two patches changing the same file and
        submits them separately because they fix different problems
        while at the same time commiting them to a private branch
      * a developer commits the first patch literally on the trunk
      * the contributor pulls trunk and propagates to his branch (no
        conflicts)
      * developer commits second patch literally on trunk
      * pulling and propagating again works without conflicts

I think the key reason why this works is that the developer recreates a
revision as it exists on the contributors branch and therefore monotone
doesn't really have to do anything.

Let's try a more complicated scenario:
      * the contributor makes a change to one file, submits patch
      * he makes another change to another file, submits patch
      * OE developer accepts first patch into trunk, then modifies it
      * pulling and propagating to private branch works without
        conflicts, but this time monotone created a merged version that
        the contributor can update to
      * OE developer commits second patch
      * contributor can pull + propagate and his private branch is
        identical with trunk again

Finally a last one:
      * the contributor makes a change to one file, submits patch
      * he makes another change to another file, submits patch
      * OE developer commits the second patch first, on a branch
      * he modifies the same file to fix it
      * finally propagates to trunk
      * contributor pulls and propagates to private branch => now there
        is a conflict which needs to be resolved manually

Okay, so if there is something to be learned from this, then I suppose
it is this:
      * Contributors, keep your changes in a private branch by using
        "monotone commit -b <your branch name>" the first time you
        commit changes. The branch names is remembered for the current
        working copy, so there is no need to always use the "-b". Use
        "mtn pull && mtn propagate org.openembedded.dev <your branch
        name> && mtn update" to follow the main development.
      * OE developers, please, be kind to your contributors and apply
        patches literally, commit them to org.openembedded.dev and only
        then modify them.

> > > OE dev (assuming patch and change is ok):
> > > 5) updates their workspace to revision from 1)
> >
> > Even if the contributor is able to provide a revision, isn't that going
> > to be a lot slower for the core developer? It implies going back to an
> > older revision and then recompiling all sources necessary to check the
> > patch (okay, that could be skipped, but that's not desirable).
> 
> Updating to an older revision isn't hard. It's about the same thing as
> doing a new checkout or creating a new branch.

But recompiling everything that was modified by going to the other
revision is going to take time.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly@gmx.de
http://www.estamos.de/