Re: [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.

On 08/08/11 07:37, Richard Riley wrote: > David Soria Parra <dsp@php.net> writes: > >> On 2011-08-07, Stas Malyshev <smalyshev@sugarcrm.com> wrote: >>> Hi! >>> >>> As somebody that have seen reasonably big project switch from SVN to git >>> and worked quite actively with git since then, I think describing my >>> experience might be useful for those that never tried it. >>> >>> 1. git is much better than svn especially as applied to complex projects >>> with multiple participants which need to accept outside patches, >>> maintain multiple branches and port fixes between branches. You never >>> know how much you needed cheap branching/merging until you worked with >>> it some. >>> >>> 2. Switching from svn to git requires one to undergo some mental shift, >>> and for the first couple of weeks you may be confused and somewhat >>> frustrated by too many things that look like but not exactly like the >>> old system. It would appear too complex and unnecessarily complicating >>> workflows. However, as you develop new routines, you'll find out how it >>> makes sense and will become more effective than with svn. Note that git >>> IS much more complex conceptually than SVN and allows to do much more >>> crazy things - including rewriting history in all kinds of weird ways - >>> so while I don't think I had to ask SVN question in forums for years - I >>> still have to google "how to do this in git" and ask around for some of >>> the more complex things. I think it's still worth it. Don't know if it >>> makes me a fanboy :) >>> >>> 3. Having system like github around it adds a lot - maintaining multiple >>> repositories, forks and pull requests is a real boon. I'm not sure if it >>> would make sense for php, all things considered, but there are very >>> significant benefits of using such a system where many workflows are >>> already built-in. >> having a dvcs will enable us to use pull requests in github. (maybe >> you will not able to use the big merge button but rather do it yourself, >> but still it's a huge improvement). > > Its really simple. > > Use git. > > It works, is fast and is rapidly becoming the industry standard. Do not > sue something for "moral grounds" like the awful bzr used for emacs. > > Its designed as a fast, efficient DVCS. > It's not bzr's fault that someone had the bright idea of setting up the server to serve the emacs' repo via a slow "dumb" protocol (sftp). I've been using mercurial for the past 2 months and Bazaar for the past 4 years. My personal preference is Bazaar as it handles my workflow much better than Mercurial does. Mercurial seems to encourage a "commit everything to trunk in a linear fashion" like svn. Named branches seem to be the only way to ensure that a merge comes in as a single commit rather than a "fast-forward merge", but they're discouraged for some odd reason. Maybe there are some extensions that make mercurial easier to use in this regard, but I haven't looked too hard. Maybe that's not a big problem for some projects, but for me, I like to know when a particular feature was landed in trunk, and what commits are related to it, so when I revert a change, I'm only reverting a single commit rather than having to weed through the tree to find all the commits that need to be reversed. And if I'm "doing it wrong™", please let me know off list how I can improve things. I have not used git yet, so I can't comment much there other than that the impression I get is that it's probably the most capable system out there, but where it still has a ways to go is usability. I hear that's getting better too, but this git-cheatsheet (http://www.ndpsoftware.com/git-cheatsheet.html) still confuses me. John Szakmeister, who is a Subversion developer himself, has a good comparison of svn, hg, bzr and git: http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Long story short, his company went with git. Cheers, David