Switch to GIT?

Next topic

Author	Message
Thomas Koch	Tuesday 15 April 2008 2:20:16 am Hi, I've been using GIT now for a month and I'm amazed. It's not only blazing fast, but can improve the whole development process. Therefor I thought to start a discussion here in the forum about the introduction of GIT (or another distributed VCS) in the development process of eZPublish. The most significant improvement that GIT could bring us, seems to me the better integration of eZSystems partners into the development of eZPublish. In the moment there are two possibilities how a partner could participate in the development. Either he has been granted SVN commit access or patches must be posted manualy to a mailinglist, forum or bugtracker. If eZPublish would be developed with a distributed VCS, then a partner can simply clone the repo and put his patch in a branch of the clone. If eZSystem want's to include the patch it is only a simple git pull away. The partner also has a big advantage, because the management of patches becomes much easier. For now we have a collection of local patches that are not appropriate for the official eZPublish release. In the moment we need to recreate the patches for every new eZPublish release. With a distributed VCS we simply rebase our patches for a new release and most of the work is done by the merge support of the VCS. What do you think? Isn't the eZPublish ecosystem much like the linux kernel? Linus includes the patches from a douzen lieutnants which in turn merges the changes coming from a douzen teams, which in turn... --- Thomas Koch \| http://koch.ro YMC - eZ Publish in Switzerland \| http://ymc.ch
Bruce Morrison	Tuesday 15 April 2008 6:43:11 am Hi Thomas I have to agree with you about Git, it has a number of advantages over subversion and with the git-svn wrapper using it with existing subversion repositories it simple and effective. I think there are a number of issues with it's use on a project like eZ Publish. Firstly many eZ publish developers, like many php developers work with windows platforms. While Git can be made to work on windows I believe it's a pain to setup and quite slow. Secondly, eZ Publish while being an open source project is not a community project. Actually the whole point of a DVCS is that you don't have to have access to the centralised VCS. There is nothing stopping you creating a git version of the repository and hosting that on, say github.com, then any one wanting to make changes just clones the initial repository makes there changes and provides their own version. It's then up to the "owner" any repository to grab any changes they want from whatever source. Dr Nic explains it much better here http://drnicwilliams.com/2008/02/03/using-git-within-a-team/ and with Star Wars & Highlander references. In the case of eZ publish I suspect that this would result in a "Community Fork" cheers Bruce p.s. I did a couple of blog posts about using git with eZ projects a month or so ago: http://suffandnonsense.blogspot.com/2008/02/using-git-with-ez-publish-projects.html http://suffandnonsense.blogspot.com/2008/03/git-and-ez-approve-2-checking-in.html My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Ekkehard Dörre	Sunday 20 April 2008 5:59:50 am Hi Thomas and Bruce, GIT is not the only interesting VCS: Pro and Contra from the bazaar view: http://bazaar-vcs.org/BzrVsGit http://bazaar-vcs.org/BzrVsSvn http://bazaar-vcs.org/BzrVsHg http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html We are still using SVN, but it does not fit well any more. Many different servers, eZ versions, PHP-Versions, extensions and extension versions, eZ patches, many different places, where the developer are and many OSses. You need: + Different eZ versions * Different PHP-Versions * Different eZ extensions for different eZ versions and PHP Versions * Different eZ extensions for one extension for different customer * Different configurations for different servers, databases, server software (Apache, Lighty, OpenOffice, Red5, ffmpeg, imagemagick, for find and so on) * Many different developer, companies each with projects of more than 5 years of development = uncountable complexity and the keep all these servers up to date with version control. A software should adapt the human workflow and not the human the given software workflows. http://bazaar-vcs.org/Workflows @Bruce: As a result a community fork? This is a political point and not a point from VCS software. It is sometimes not easy to get important patches into the core and I think, many of us have patched versions running, but far, far away from a fork. Read "Decentralized systems do not encourage forking" http://bazaar-vcs.org/DecentralizedArguments And as a nice overview: Intro to Distributed Version Control (Illustrated) http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Greetings ekke http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing
Bruce Morrison	Sunday 20 April 2008 4:54:06 pm @Ekkehard As a result a community fork? This is a political point and not a point from VCS software. . Yes and No. DVCSs do allow for much easier forking as it's part of their fundamental nature. However I'd agree with you that it's largely a political issue. In the same breath I'd say that eZ publish is the most frustrating OS project I've worked with in terms of contributing back bug fixes. ( for me this is an ethical part of using OS software ) You seem to hint at this with your comment It is sometimes not easy to get important patches into the core and I think, many of us have patched versions running, but far, far away from a fork When ever I encounter a bug I a supply a patch or at least code that demonstrates the issue, I've been doing this for years. I've recently had 2 bugs with patches looked at that were in the 2-2.5 years old range (3.6 was the current version). (I didn't know whether to laugh or cry when the notifications came through). Admittedly there were not critical and while I'll continue to supply patches to bugs I find it's not a process I look forward to participating in. So my point is that DVCSs allow for easier forking than centralised systems, with the increased awareness, maturity and access to DVCS tools and the nature of the eZ publish "community" I would not be surprised to see a community fork. The link you supplied: http://bazaar-vcs.org/DecentralizedArguments seems to describe the current situation clearly. Handled correctly I think a community fork could be an extremely healthy thing for both eZ systems & the community. While quite different in nature, the Red Hat/Fedora projects may act as a good template. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Thomas Koch	Wednesday 23 April 2008 5:06:03 am I've imported the ezp svn into GIT via git-svn init --trunk http://pubsvn.ez.no/nextgen/trunk \ --tags http://pubsvn.ez.no/nextgen/versions The import ran over two and a half days to import the whole svn history into git. I hoped it would put all versions as branches into GIT, but in the final GIT repo I can not see them. Nevertheless I put the GIT repo on my private server to get us a sandbox. Clone via: git clone git://koch.ro/git/ezpublish Putting the GIT repo online is really a no brainer compared to setting up a svn server! I'll have a cronjob to run git svn rebase every hour to keep the repo in sync with ezp svn. Please expect this repo to become unavailable anytime since it is only intended for testing and training. --- Thomas Koch \| http://koch.ro YMC - eZ Publish in Switzerland \| http://ymc.ch
Thomas Koch	Tuesday 24 June 2008 1:26:42 pm I'd like to recommend you a talk and slides from Railsconf 2008. The slides are very nice made and a voiceover video is available: http://www.gitcasts.com/git-talk This introduction to GIT is the best I've seen so far and I plan to reuse the slides for inhouse training. --- Thomas Koch \| http://koch.ro YMC - eZ Publish in Switzerland \| http://ymc.ch
Thomas Koch	Tuesday 30 September 2008 11:22:42 am There is a new version of my eZ Publish GIT repository at http://git.koch.ro/?p=ezpublish;a=summary Clone it via git clone git://git.koch.ro/git/ezpublish It was possible to get all the tags and branches from SVN into GIT, too. Just browse a little bit through your local ezpublish clone with gitk or tig to see how life changing it could be to have the whole history at your fingertip. git blame is a matter of seconds! :-) --- Thomas Koch \| http://koch.ro YMC - eZ Publish in Switzerland \| http://ymc.ch
zurgutt -	Saturday 04 October 2008 4:52:01 am Excellent, i will check it out - used to bzr myself but git should not bee too alien. And cheers for community fork - we could finally get some bug and usability fixes into it! Certified eZ developer looking for projects. zurgutt at gg.ee
Kristof Coomans	Thursday 11 December 2008 9:33:13 am I'd also like to see a more important role for our community in the development and bug fixing process of eZ Publish. Preferably, eZ Systems should make this possible. But, in the other case, a community fork, or, a community bleeding edge features edition of eZ Publish of which things are possibly merged back to the main eZ Publish product, could be a very good thing, at least if it can attract some good community developers. And for the reference, an article in Thomas' blog on this topic as well: http://www.koch.ro/blog/index.php?/archives/96-GIT-for-the-eZ-Ecosystem.html independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org