[oe] Reconsidering the work flow and how the SCM system fits in
Mike (mwester)
mwester at dls.net
Tue Mar 11 13:09:17 UTC 2008
[top posting to save readers time]
+100 from me (can I do that?) --- as a long time SCM proponent (SCM
consulting has clothed and fed my family and put a roof over our heads
for many years), I am hugely in favor of switching to another tool and
using features such as branching!
I haven't used git myself, but from what I've read, it seems to be the
logical choice, so I concur with that choice as well.
(It would be so incredible to have a proper tool for branching and
merging - this would make me rather happy!)
Mike (mwester)
Holger Freyther wrote:
> Hey,
>
> I'm anything but happy with the way we work with our repository. We have a
> dreambox branch that is not mergable due issues with our SCM system, the
> OpenMoko guys have to go back to diffing and applying the diff and merging by
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs
> in one go and then do weeks of fixing. And I can continue with this list.
>
> What: I think we should use more branches
> - As many shortlived and medium lived branches as developers want
> - Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
> start the development, add features, other people will compile their stuff,
> other compile and then you rebase and merge!
> - Basicly you develop a feature in a branch until it is ready and not
> impacting other things, then you rebase/cleanup, propose it for inclusion
> and wait for feedback, then merge.
> - Stable distributions and vendors get their own branch, they can merge,
> cherry-pick what ever they want.
>
>
> The issue:
> - mtn can not merge. Forcing me to manually delete files in one copy to do a
> merge is not acceptable.
> - mtn has not the concept of short-lived branches (e.g. deleting their
> existence once done), mtn suspend does not work as witnessed by our
> automerger.
> - mtn pluck is not making me happy
> - I lack a GUI to easily browse the repository
> - I can not clean up changes before I push them!
>
>
> I want that we use more branches for development, apply review on them,
> land/merge/push these branches after review, pull peoples changes from other
> hosts, work on perfetch patch series before landing patches. I believe we
> need to deploy this kind of development in OE again and as mtn is the
> obstacle to this kind of development I propose to switch to another SCM
> system that allows us to develop OpenEmbedded the way it should be developed.
>
> My criteria:
> - Should have branches, easy merging, easy merging of merges
> - Branches and merging should be cheap
> - Make it easy to put the OE tree into another SCM and still be able
> to merge (git-svn and such)
> - A good graphical tool to browse the repository
> - A good and maintained web frontend
> - A good set of builtin tools (e.g. like git-add -i and git-rebase -i)
>
> I think the two options are hg and git, I tend to favor git due the size of
> its community. I want to switch OE to one of these systems by the end of this
> month and start using more branches and creating perfect patch series again.
>
>
> comments? agreement?
>
> z.
>
>
> PS: It is not the speed of mtn, it is the lack of development in areas like
> branches, merging, rebasing, we need to use these in OE!
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
More information about the Openembedded-devel
mailing list