Re: Reconsidering the work flow and how the SCM system fits in

["Mike (mwester)" <mwester@dls.net>]

[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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>