Re: A question of workflow

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

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.

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

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

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

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.

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

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