[oe] A question of workflow

[Justin Patrin]

On 1/8/07, Patrick Ohly <Patrick.Ohly at 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. 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. If a contributor makes
a change in their own branch and then it's comitted seperately to .dev
then they're 2 different revisions.

>
> > Monotone uses the revision graph to deal with merging and your local
> > commit still wouldn't likely be the same revision as what the dev
> > comitted.
>
> I'm on thin ice here because I don't know monotone well enough, but
> isn't a common ancestor enough to do the three-way merge that has a much
> better chance of avoiding merge conflicts? There is guaranteed to be a
> common ancestor for external and core OE developer even if both work
> with branches because both share the same OE trunk.

With my workflow you have a common *revision* and this means that
monotone can realy do the merge work for you.

>
> > Hmmm, now that I think of it this workflow might work:
> >
> > Contributor:
> > 1) notes current (.dev) revision they are using in their workspace
> > 2) makes changes
>
> As you said, this assumes that the contributor always develops the patch
> against the oe.dev branch. The more likely situation with an active
> contributor is that he has multiple pending patches that he needs to
> continue with his work. He might store them using quilt/patcher or in a
> monotone branch, but in either case the base revision of a patch is not
> something found on the oe.dev branch.

This is easily solveable. The contributor can use the latest official
.dev rev and make their patch, then commit. Once this is done they can
merge/propagate to their own branch.

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

>
> In my "temporarily branch on commit" proposal the developer would be
> able to keep working with the currently checked out and compiled
> revision of the meta data, although admittedly reusing the same branch
> name requires some more thought - I'm not exactly sure how to do that
> with monotone.
>

As long as we create the same revision, merging is going to be much
simpler. Even if a dev has to go "back" to commit the patch then they
can simply merge with head and be back up to current.

> Anyway, all of this is idle speculation unless one or more of the core
> developers are willing to adopt such a method.
>

Some comments from monotone developers would be nice. Nathaniel, are
you listening?

-- 
Justin Patrin