Hi everyone,<br><br>Over the past few months, we have been using Git for source control of the ImageJ2 effort. However, for a number of reasons, I would like to migrate the repository to Subversion instead. I am soliciting feedback from anyone who has a preference one way or the other, as well as input on the issues below, so that we can reach a consensus as a group.<br>
<br>1) Git support on Windows is weak compared to SVN<br><br>Our current Git workflow on Windows is to install msysGit, optionally TortoiseGit (which requires msysGit), as well as Putty/Pageant, for proper handling of SSH keys. And we're still struggling to make this configuration work. Conversely, for SVN, we install TortoiseSVN, add the user through the Trac administrative interface, they type their password the first time they perform a commit, and it is cached thereafter. Security-wise this is probably inferior, but it is much easier to set up.<br>
<br>2) Git support in NetBeans is weak compared to SVN<br><br>NetBeans interfaces with Git through the NBGit plugin, which is only partially implemented. For example, I could not figure out how to switch branches using NBGit. Conversely, NetBeans has full built-in support for SVN. TortoiseGit provides an alternative GUI-based solution, but is unfortunately several times slower than command line Git.<br>
<br>3) Git allows dangerous operations like rewriting history and deleting branches<br>
<br>In some ways this is great, and it's a pain that Subversion doesn't. However, there is a certain security in knowing that no matter what you do in SVN, you can always backtrack. For example, the other day I accidentally deleted the old ijx branch containing Grant's original refactoring work, and did not realize it until later. In this case it is not catastrophic, but it scares me that users can so easily delete big chunks of the repository. Even if it is possible to undo, I simply do not know enough about Git to know how to do so, or even necessarily realize such a thing has happened.<br>
<br>
4) Git does not allow partial tree checkouts of the repository<br>
<br>With SVN you can checkout a subtree of the repository, allowing you to place a large number of modules off the root, and instruct people to check out and build only what they want (and Maven makes this especially easy). AFAIK you cannot do this with a single Git repository, but would need one Git repository per module instead—which then complicates checking out the entire umbrella of projects instead. I know submodules are a partial solution, but they have their own problems as well.<br>
<br>5) Git uses non-linear versioning, making it more difficult to refer to development builds<br><br>The fact that every checkout of Subversion is linear and has a monotonically increasing number is exceedingly useful for stamping builds. With Git, AFAIK you can't easily do this. An article at <a href="https://wincent.com/blog/automatic-deployment-numbering-in-git" target="_blank">https://wincent.com/blog/automatic-deployment-numbering-in-git</a> discusses a possible workaround, but it is deployment-based. We want the revision number to match a particular snapshot of code, so that external developers can easily check out that particular revision and get source code that matches the build in question.<br>
<br>6) Git is harder to understand and use than SVN<br>
<br>Apologies in advance if this statement starts a flame-war. However, I've witnessed the vast majority of developers with whom I've interacted struggle with Git's learning curve compared to SVN. In particular, I am personally frustrated with the complication of local branches vs. remote ones. And I know that the choice of Git has been a barrier to adoption for Grant as well—as mentioned above, Git's GUI tools, especially on Windows, are not as polished as they are for SVN.<br>
<br>7) Our development server—Ubuntu, serving Git code using Gitosis—produces mysterious (but seemingly harmless?) error messages; e.g.:<br><br><div style="margin-left: 40px;">curtis@rook:~/code/LOCI/imagej$ git pull<br>
error: ssh died of signal 13<br>
Already up-to-date.<br></div><br>It's probably a minor issue, but I haven't been able to find a solution via web searches.<br><br>8) Git does not integrate with Trac as well as SVN does<br><br>This is also a minor point, since the Git-Trac integration is actually quite nice. However, there are a number of issues (documented at <a href="http://trac-hacks.org/wiki/GitPlugin%29" target="_blank">http://trac-hacks.org/wiki/GitPlugin)</a>—in particular, performance (#746) and branch display issues (#2633).<br>
<br>In conclusion, I am frankly frustrated with Git, and feel SVN would be an easier choice for both our own development team as well as the larger ImageJ community. However, I welcome discussion, as there are certainly downsides to switching away from Git.<br>
<br>-Curtis<br><br>