Skip to end of metadata
Go to start of metadata

<p>We are considering infrastructure changes for ZF 2.0, and want input from the community.</p>

<p>In particular, we are weighing whether to stick with Subversion for ZF 2.0 development, or to move to Git. There are several pros and cons to each.</p>

<h2>Git</h2>
<h3>Pros</h3>
<ul>
<li>
<ul>
<li>No need for ACLs. Each developer maintains their own fork, and issues pull requests to the appropriate maintainer(s). Only trusted maintainers would have access to push patches into the main branch.</li>
<li>Lower bandwidth and storage needs (git is very efficient in regards to compression)</li>
<li>Cheaper branching; easier to work on many bugs in parallel with the main branch</li>
<li>Easier path to establishing community release masters</li>
<li>Potential for organizing better/different workflows than SVN currently supports</li>
<li>Provides some more useful paths for aggregating different areas of development (library/test code versus documentation versus tooling etc)</li>
</ul>
</li>
</ul>

<h3>Cons</h3>
<ul>
<li>
<ul>
<li>Tracking CLAs becomes more difficult. Currently with SVN, we only grant access to those who have signed a CLA; if anybody can fork, we now need some way to verify CLA status before pulling patches.</li>
<li>No good svn:externals equivalent</li>
<li>Tooling across platforms is not as mature or robust</li>
<li>Would potentially require (re-)training contributors</li>
</ul>
</li>
</ul>

<h2>Subversion</h2>
<h3>Pros</h3>
<ul>
<li>
<ul>
<li>Established processes</li>
<li>Established CLA/ACL relationships</li>
<li>Mature toolsets available cross-platform</li>
<li>svn:externals as distribution mechanism
<h3>Cons</h3></li>
<li>Distributed model flattens the barrier to contribution; non-distributed presents barriers (getting access is harder)</li>
<li>Fewer workflow options (cannot track multiple remotes, cannot create throwaway branches, etc.)</li>
<li>Only users with appropriate authorization can create branches</li>
<li>Requires more storage and bandwidth</li>
<li>Single tree paradigm makes organizing code more difficult.</li>
</ul>
</li>
</ul>

<p>We'd like to hear from you, our contributors, to determine what you would like, and why. Please omit "fanboy" arguments – simply stating you like or prefer one approach over the other is not enough; explain why.</p>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 24, 2010

    <p>You missed a pro for SVN, its currently working!</p>

    <p>that said, svn:externals also causes a pain when pulling a fresh checkout currently, waiting for all of the dojo tests seems to take an age!</p>

    <p>I feel that git would be a good step forwards for ZF if the cons regarding sorting the verification of CLA status can be resolved (Though can this not be done by checking a users groups on JIRA?).</p>

  2. Feb 24, 2010

    <p>One thing that is important to me, is that if somehow the ZF server crashes, and the backups are lost, there are no problems when you use git. Because then you always have backups. Then you probably have some forks at github, git.or.cz, Zend employees and other places. And you can verify the correctness pretty easy with just the 20 bit SHA-1 hash.</p>

    <p>Also you got github, which helps collaboration a lot in my opinion. It already has a great toolset for viewing the code and commits in someone's repository. And you can easily fork it, and filing pull requests is quite easy too.</p>

    <p>Another thing: collaboration. Some time ago, with Zend_Markup, I had some changes I wanted to show to somebody else, but the problem was: I just couldn't commit because it was breaking the trunk otherwise. And thats something you don't want to do at all with SVN. With git, you don't care. I could commit, and everybody else who would be working together with me, could just pull from me. Later on, we could even squash it into one single commit if we wanted to, and then file a pull request on the main ZF repo.</p>

    <p>And something what I think is important for some of us: being able to work offline. If I am flying over the atlantic, and I am working on ZF, I want to be able to commit too. But I can't, because I don't have any connection! But if I'm using git, it will all go smoothly, and I just push when I have connection again.</p>

    <p>Though, I have one other con for git. Git has proven to be a UNIX-tool, which means that it doesn't really work perfect on windows. Yes windows developers have msysgit, but there still are some flaws in there.</p>

    <p>But being a real UNIX-tool isn't really bad. It also means that besides of some high-level porcelain commands, it also has low-level plumbing commands that can help people to retrieve lost commits due to disk corruption, and other failures.</p>

    1. May 04, 2010

      <p>We use Beanstalk, it's similar to Github but has support for SVN & GIT under the same plan & disk space. It's really nifty and if ZF2 goes to only git, we will be able to handle the migration without switching collaboration sites. One thing to note is that Beanstalk is private only.</p>

  3. Feb 25, 2010

    <p>What makes Zend Framework so phenomenal is the community behind it.  I think Zend Framework will ultimately have to side with the platform that dedicated developers choose, and that seems to overwhelmingly be Git (hosted on Github for the most part). It significantly lowers, in my opinion, the barrier to collaborate on documentation and code. Also, it would allow users to find forks of the framework that addresses specific niche needs (that haven't been adopted in the official repo yet), and encourage the community that much more.</p>

    <p>By and large, top developers have been forking & maintaining Git repositories on Github for quite sometime now.</p>

    <p>Yes, the requirement of CLAs could be a potential pain point. Perhaps we could tie their Github account to their Confluence login (+ CLA). Let a script decide whether or not to perform a `git pull <remote>` to simplify the process significantly.</p>

    <p>With the proper folder structure, .gitsubmodules works pretty well, especially for pure downstream repositories. I do prefer how svn:externals allows you clone deeper in the repo.</p>

    <p>From what I've seen, many Git developers are using a branching/merging strategy similar to this, with appropriate modifications:<br />
    <a href="http://nvie.com/archives/323">http://nvie.com/archives/323</a></p>

    <p>Zend_Tool could even be augmented, if so desired, with Git Flow-like functionality (<a href="http://github.com/nvie/gitflow">http://github.com/nvie/gitflow</a>) to ease the burden for contributors.</p>

    <p>What if a trial "Bug Hunt Month" was hosted using Git (maybe on 2.0 branch, since it's so experimental) to test out the workflow amongst potential contributors? I'm sure we can prove a working model before committing early on to such a drastic (potentially beneficial) change.</p>

    <p>The ZF2.0 code base will exist for quite some time. Will we really see developers continue to stick with SVN (who's branch/merge mechanism increasingly difficult to work with successfully) as time goes on? The question really is, which system would allow greater collaboration on Zend Framework and encourage community involvement more.</p>

    1. Feb 25, 2010

      <p>The biggest problem with submodules/svn:externals, is that all the current externals use svn. And importing a svn repository into git takes quite some time. Which means that Zend would probably need to mirror the codebase of all externals in git.</p>

      <p>Also, keeping track of CLA's probably isn't that hard. Just make a hook for pushing into the server, and if it contains a commit with an author of which it can't resolve a CLA, just reject the push. But I don't like the idea of not being able to pull when you don't have a CLA. A warning for this would be a lot better.</p>

      <p>Also, I'm quite sure that only the 2.0 branch would be hosted on git. Porting the 1.x branch to git would be horrible. You can only really do such a switch with new major versions.</p>

  4. Feb 25, 2010

    <p>I have just started using git, but I already feel the power of the distributed model. It means finally not having patches that sit in jira anymore, ensuring that no work is lost in the bug tracker.<br />
    I know it can be difficult to learn how to use a new source control system but the earned knowledge will be valuable also on other projects (PHPUnit is now hosted on github.)</p>

  5. Feb 25, 2010

    <p>I would prefer SVN. It is widely adopted and the tooling support is great. And most IDEs support SVN, Git is very seldom support, even the Git-Eclipse-Plugin does not work very well.</p>

    1. Feb 25, 2010

      <p>Exactly... +1 vote for svn <ac:emoticon ac:name="smile" /></p>

    2. Feb 25, 2010

      <p>I second that .... +1 vote for svn :-D</p>

    3. Feb 25, 2010

      <p>I disagree, The jGit code is quite robust and both the eclipse git and netbeans Git plugins work very well indeed.</p>

      <p>Please don't just add "+1", at least offer some sort of valid reason that you wish to stay with SVN other than it's what you currently use.</p>

      1. May 04, 2010

        <p>I'm guessing the vote means they agree (hence "Exactly) with Tobias's points. I also appreciate the wide range of support for SVN, especially in Eclipse. +1 SVN.</p>

  6. Feb 25, 2010

    <p>+1 for SVN, svn tools are installed automatically on linux/unix, git isn't. That's important for shared hosts like dreamhost for example.</p>

    1. Feb 25, 2010

      <p>Not true, svn never was installed by default on ubuntu. And git is installed just as easily as svn.</p>

      <p>Also, people using shared hosting probably don't use SCM anyways. And the hosting company itself should not care about what one of many frameworks uses. Hosting companies mostly don't even care about SCM.</p>

    2. Feb 25, 2010

      <p>On your production server, even in shared hosts, you shouldn't really be using a VCS; you should have a deployment process that exports from your VCS and either packages the release for you or pushes it to your production server. As such, I think this is argument should not be weighted too much.</p>

      <p>As for svn being installed automatically on linux, I have never found that to be the case, and I've used a ton of different distros. I can't think of the last time I <em>didn't</em> need to install any VCS tool myself – though, admittedly, in most cases the tools are available via the distro's packaging/update mechanisms. This is true of git as well, however.</p>

      1. Feb 26, 2010

        <p>I actually use git on my production servers; it has some rather nice benefits. Using Capistrano (I've never liked phing-style deploys) a deploy simply consists of a `git pull` from the release branch (lightning fast) and then a hard-link of the repo to the destination directory, skipping the .git folder. The same can be done with SVN technically, but it requires skipping of <em>all</em> the .svn directories (slow and annoying).</p>

        <p>It's also great for managing /etc <ac:emoticon ac:name="smile" /></p>

      2. Sep 24, 2011

        <p>While I've never experienced a VCS being installed by default, I do use one as part of my deploy process. With SVN there is an export subcommand.</p>

        <p>However, I don't think any of that matters for the ZF project VCS. Users can chose what ever VCS they want for their code.</p>

  7. Feb 25, 2010

    <p>I think using Git for development on the framework makes a lot of sense - the workflow is brilliant. However, we have stuck with SVN internally at my company because we rely heavily on externals to link in our own internal framework in addition to Zend and other external resources we rely on (Git modules just don't work as well). This is very convenient because we are able to link to the most recent "dot" version of Zend Framework and then get bugfix releases automatically every time they are updated in the repository. Even if most of the core development on the framework takes place in a Git repository going forward, it would be very helpful to still have the releases pushed out to SVN for people who rely on externals in their own projects.</p>

  8. Feb 25, 2010

    <p>Git has always seemed a more natural fit for web development. </p>

    <p>A distributed system works well because the contributors are also distributed, Git is designed for the type of collaboration that ZF requires. With Git, if you are a ZF developer or contributor there would be no reason <strong>not</strong> to have a complete copy of the repo. This would highly increase the chances of even small patches of fixes trickling back upstream.</p>

    <p>Git is an order of magnitude more flexible and powerful than SVN. Any contributor or ZF application developer could have dozens of remote tracking branches ready to pull from at a moments notice. And of course productivity is vastly improved using Git because of the cheap, fast and easy nature of Git branches. I would wager that a high percentage of contributors already use Git as an SVN client. And merging... merging is easy and fast too, from local branches or tracking branches, it doesn't matter, you branch, you merge. You do it so often and so easily you can't easily go back to SVN merges without incredible frustration.</p>

    <p>The Git branching/merging model alone should be enough to warrant a change to Git. Git merge makes the job of a component maintainer or release master so much easier.</p>

    <p>With the core ZF team using agile development and new features in every minor release Git is eminently more suited to the ZF development model. SVN is better suited to waterfall in-house development.</p>

    <p>One simple way to ensure that code only from people that have a signed, approved CLA is merged by maintainers/release manager is to make use of the tag signing capability. When a CLA is approved, issue a signing key to the signee. If I then want Matthew to merge my fix/patch/feature I then simply tag the commit and sign it.</p>

    <p>Me: git tag -u /path/to/my/zf_cla_key.rsa <tagname> <commit> -m "new feature Zend_Magic"</p>

    <p>Matthew pulls from me to a local feature branch and does: git tag -v <tagname>, if the key is verified he can merge...</p>

    <p>To address some of the other cons listed for git:</p>

    <p>"No good svn:externals equivalent"</p>

    <p>Distributing 100MB of Dojo project was not a good Idea anyway in my opinion. With the ability to use CDN's in the placeholder the only people who would really want the full distribution are those building their own Dojo layers, and they are more than capable of grabbing the full distribution from the Dojo project if they need it.</p>

    <p>"Tooling across platforms is not as mature or robust"</p>

    <p>Windows implementations are more than usable, if the objection is because there's no pointy clicky interfance then the objection is without merit.</p>

    <p>"Would potentially require (re-)training contributors"</p>

    <p>If you can't grok git basics after one day of using it, why are you a developer? In the past Git was accused of being too complex, this is probably a fair criticism but not anymore. Git basic operations are simple and easy to understand.</p>

    1. Feb 26, 2010

      <p>Great idea Graham. I never knew of the -u option to git-tag, but it seems a great fit.</p>

  9. Feb 25, 2010

    <p>I would also like to add my +1 for the move to git.</p>

    <p>I was skeptical about the benefits that git would bring originally but I have now been using it for over 6 months on a number of other projects which have all migrated from svn to git and I now love working with it.</p>

    <p>Its made the whole development process for me much easier. I haven't tried the git submodules functionality yet but this could be an option for replacing svn:externals.</p>

    <p>I agree with Grahams comments that the Dojo stuff really isn't that important to distribute (IMHO) so maybe that's easily solved?</p>

  10. Feb 25, 2010

    <p>I see benefits for both SVN and GIT. The problem some people see with svn:externals going away is not really a problem, since that can/should be solved by a proper build-script anyway. What would GIT less ideal would be, if only a handful of people had commit access to the main repository, as that would slow down the entire colaboration process pretty much.</p>

    <p>The problem with CLAs is actually a bad one. Grahams idea with signing tags doesn't sound really well, since it would add extra work to both the patch-writer and the release master. In my opinion GIT would be a no-go if it would make the current process any more complicate or add additonal required steps.</p>

    1. Feb 25, 2010

      <p>I'm not sure how the CLAs are stored, but this is a trivial problem at best. Simply put, have a script check if the forked repo's user has a CLA before pulling. Done. Authenticated commits are just an added bonus.</p>

      <p>What many people are missing here is there are <strong>tons</strong> of developers that would love to contribute to Zend Framework, but the process is too complex as it is. If your dev environment uses your forked copy and you discover a bug, you can fix it right then & there, commit, and submit a pull request.</p>

      <p>Only main (Zend) developers should have access to the master repo to protect it's integrity. Forked repos, as described in Graham's comment, would encourage active improvements to the codebase.</p>

      <p>We're seeing lots of comments supporting SVN simply because of svn:externals, or because their deployment script or workflow uses SVN. The most pressing factor in determining Git vs Svn, in my opinion, is <strong>which platform encourages & facilities community activity in Zend Framework</strong>.</p>

      <p> Personally, I've found contributing via SVN (especially with documentation) painful as best.  But, I certainly don't know what's best for the Zend Framework community.  I've seen other major frameworks benefit greatly from Git.  What I recommend, as I mentioned above, is simply testing it.  At the very worst, we can go back & create .patch files from the diff of the code & submit them the old fashioned way.  But such a hefty decision shouldn't be taken likely and simply decided by personal preferences.  Let's see it in action.</p>

      1. Mar 17, 2010

        <p>I like the idea of testing g/it.</p>

  11. Feb 26, 2010

    <p>I think this is an excellent idea.</p>

    <p>I've been using git (and git-svn) for about three years now, and have never regretted the change.</p>

    <p>One side effect of using git that I haven't seen mentioned is that my code quality has improved. I wish I had data so I could give a metric, but I'll just say "by 50%". Why? `git add -p`</p>

    <p><ac:image><ri:url ri:value="http://localhostr.com/files/e3d195/Screen+shot+2010-02-26+at+3.30.34+AM.png" /></ac:image></p>

    <p>The ability to step through chunks of my changes and approve or skip each of them gives me one last chance to review what I'm about to commit. The highlighting allows me to focus on each change individually to see if I left anything stupid in. I have a tendency to leave xdebug_break() and var_dump()'s all over the place, but almost never commit one due to this. Also, who needs an IDE tool when your CLI looks like this? <ac:emoticon ac:name="smile" /></p>

  12. Mar 11, 2010

    <p>I'm in favor of Git because of local branches. If I want to work on a proposal or fix a bug I could easily branch from trunk. The biggest benefit is that if someone wanted to help me they could just checkout my branch, and we could collaborate together without disturbing the main ZF repo.</p>

    <p>With SVN, if I wanted to work with someeone on a bug/proposal we'd have to set up a whole new repo since I don't have commit privileges. I usually end up creating the new repo in Git anyways.</p>

    <p>Overall, I think Git would help encourage bug fixes / proposals because it makes it easy for any developer to contribute.</p>

  13. Mar 13, 2010

    <p>My opinion: when you evaluate this, you have to make a distinction between ZF contributor and ZF user feedback.<br />
    Without having used GIT, I understand it is the preferred choice for contributors.<br />
    When looking at users, you probably have thousands or more projects linking with svn:externals and a lot of these users/companies will probably stick to SVN for a long time.<br />
    In that light, I think it is safe to say that, at a minimum, you need to keep up the SVN or the (corporate) popularity of ZF may suffer.</p>

    <p>If you can properly mirror the GIT repo to SVN, that sounds like a great solution to me.</p>

  14. Mar 24, 2010

    <p>Why only pick between git and SVN? Why not include Bazaar or Mercurial in the discussion? <br />
    Bazaar is probably the easiest for SVN users to work with, and Mercurial has fairly extensive IDE support. They're also a bit better on the cross-platform side of things.<br />
    Seems that the decision has already been made though... oh well.<br />
    I guess the git repo can be mirrored on Launchpad though.</p>

    1. Mar 25, 2010

      <p>The primary reason has been due to developer interest. There has been very little interest amongst the contributor community for solutions outside git or svn.</p>

      <p>Currently, we are looking at having a read-only svn mirror after the migration; I think having mirrors in other version control systems makes sense as well – but we'll need a single, canonical repository to which changes are pushed, and that's what we're deciding on here.</p>

  15. Apr 29, 2010

    <p>As long as there is an SVN read-only mirror, then I don't think there's any problem for the project to go to Git. Many people depend on the svn:externals feature for pointing to a library/Zend release tag. I'm sure there is a way to hack or script an svn:externals equivalent for this in Git. Unfortunately, I know at my work replacing Subversion for Git is not in the cards. So maintaining backwards-compatibility for this feature of Subversion is a requisite for new releases of ZF.</p>

    <p>So please factor the time and effort for the project to manage a reliable SVN read-only mirror in your decision to switch to Git.</p>

    1. May 04, 2010

      <p>Agreed. I can think of a handful of teams, including my own, that rely on svn:externals heavily. Maintaining backwards compatibility with these customers is imperative.</p>

    2. May 04, 2010

      <p>As noted in a previous comment, we plan to keep a read-only SVN mirror of the repository for use by those wanting to use svn:externals. Additionally, I'm trying to setup the repository such that we can also have separate sub-repositories that can be pulled in as git submodules (such as the library/ tree). </p>

  16. Jul 10, 2010

    <p>I think its the worst choice. Because:</p>

    <p>1. Every time ZF keeps on changing, if you compare with kids, they break working one and wants new toys. But we are here to make a framework/standard?</p>

    <p>2. Git and Svn its a useless point, its a freedom of choice, for a human being or developer.</p>

    <p>3. Let drupal/cakephp/other grow like a monster rank, and We Zend framework, shrinking ship, thinking Git or SVN? In place of putting seriousness in bug solving/new adapters!!</p>

    <p>I mean come on? This is really a disappointing page.</p>

    1. Jul 10, 2010

      <p>1. If you don't keep changing, you will get left behind. Without innovation, you will never be able to reach anything.</p>

      <p>2. Yes, its a freedom of choise for us too. And we as ZF developers chose for Git this time, while it was SVN in the past.</p>

      <p>3. Making good software doesn't just depend on the developers, it also depends on the tools. You can have the best developers around, but if your tools suck, you can't get anything done.</p>

      <p>So what is your problem? Does it bother you that we put a little bit of time in improving our toolset which we could have used for solving bugs or creating new adapters? Well actually, it works the other way around too. With better tools, you need less time for managing them and they can help you speed development up. And hey! We can use that extra time to solve bugs!</p>

      <p>Also: yes it would be great if we could eliminate politics in open source projects. But this simply isn't possible.</p>