[oe] Reconsidering the work flow and how the SCM system fits in

Justin Patrin papercrane at gmail.com
Fri May 2 05:30:40 UTC 2008


2008/3/13 Marcin Juszkiewicz <openembedded at haerwu.biz>:
> Dnia Wednesday 12 of March 2008, Paul Sokolovsky napisał:
>
> > "Leon Woestenberg" <leon.woestenberg at gmail.com> wrote:
>
>
> > > Multiple heads and lightweight branches are two different things.
>  >
>  > Probably also because of different numbers of hexadecimal digits?
>  >
>  > > A branch has a name/tag that tells me what is happening in that
>  > > branch or who is making it happen.
>  >
>  > And heads have head revision and change logs too!
>
>  And gets automerged by our monotone server.
>
>
>  > Well, but the talk was about mirroring and syncing potentially
>  > incompatible changes. Do lightweight branches help with this?
>
>  They do. After Poky release I pushed lot of stuff which I had ready on my
>  harddisk (unversioned). With GIT I would just do 'poky-after-3.1-release'
>  branch which would die after merging with 'trunk'.
>
>  For making experiments with Poky I can create branch (via git-svn for now)
>  which will have few days of work inside which will then be merged and
>  pushed.
>

Which you can also do with mtn. Make a local branch, make your
changes, commit them locally. When you sync/push your local branch
won't be pushed to the server. When you're finished simply propagate
back to the master branch (.dev). When you next sync/push your local
revisions will go up as they are ancestors of the propagate but the
branch certs won't since the server doesn't allow that branch. Not
only do you have your own local branch which is never pushed to the
server, but you also get to keep each ofyour commits. More revision
history, more commit messages, more insight into development. Of
course, your local database still has the branch certs for you local
branch. If you want to get rid of these there are commands that will
remove them that are surely no mor ecomplicated than most of git's
commands.

-- 
Justin Patrin


More information about the Openembedded-devel mailing list