[oe] [Angstrom-devel] A question of workflow

Justin Patrin papercrane at gmail.com
Thu Jan 4 04:23:02 UTC 2007


On 1/2/07, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello Koen,
>
> Sunday, December 31, 2006, 12:07:57 AM, you wrote:
>
> []
> > Do what virtually every DSCM does to support that: make a branch
>
>   Well, that's what I wanted to ask for a long time: if I make my
> private branch in the local OE checkout, do I need to do some steps to
> ensure it won't be pushed to the upstream repo (assuming I have commit to
> .dev branch)?
>

What you would do is to create your own branch and propagate from
org.openembedded.dev to your own branch whenever you want the newest
changes. Make changes locally in your branch, put them in the
bugtracker, and when they're applied you get the new versions when you
propagate. Of course, since it's not using your branch revision as the
ancestor and we not always commit your patch as it originally was, you
will have conflicts, but c'est la vie. This is a general trust
problem.

You could also make changes in a local branch and then propagate to
org.openembedded.dev, but in this case you are basically just making
your changes to org.openembedded.dev and if you got push access to our
DB all of a sudden your branch's revisions would be pulled into the
main DB since they are ancestors of revisions in org.openembedded.dev.
The revisions in your branch would also not have branch certs (due to
our limiting of branches you can push) and so would be basically
dangling ancestors. Again, this wouldn't be good for us as it brings
in a lot of revisions that we don't really need.

I suggest option 1 where you propagate from .dev to your own branch.
Yes, you will have conflicts if we alter your patches, but there is
really no way (with monotone at least) to deal with this.

(Essentially what we are talking about here is cherry picking and
knowing where a patch came from. It's a complicated issue and not
somehting that monotone supports directly at the moment.)

-- 
Justin Patrin




More information about the Openembedded-devel mailing list