We have just finished migrating Thymeleaf from SourceForge.net to GitHub.
The new root for the project's source repositories is https://www.github.com/thymeleaf
The project website remains unchaged at http://www.thymeleaf.org, though it is served now from GitHub's Pages service. All existing links should still work OK.
Why did we do this?
There are several reasons for this. First, github is nowadays starting to be 'the place to be' for open source projects, because its code sharing and collaboration capabilities truly shine. But it also features a very nice code browser and, most important of all, it is a great implementation of a great distributed source management system: git.
Were we unhappy with SourceForge.net? Not at all. SourceForge is a fantastic tool packed with nice project management features. But Thymeleaf's codebase and community has been growing so much and so dynamically during the last months that we thought switching to git (from SVN) would ease project source management... and once we decided on switching to git, GitHub was the obvious choice --even if SourceForge also offers git repositories.
How did we do it?
We imported the SourceForge SVN repositories to git using git's support for this --and using an 'authors' file for translating SourceForge users to GitHub's--, like:
git svn --authors-file=authors.txt clone https://thymeleaf.svn.sourceforge.net/svnroot/thymeleaf/trunk/thymeleaf-2.0 thymeleaf-2.0
(This is explained here: http://help.github.com/import-from-subversion/)
But this has a problem: "git svn" does not import tags/branches, so after doing this we had to go through all the commits and select the ones that mark each of the specific version tags, manually creating those tags in git.
Also, git's great branch management features allowed us to combine the three separate SVN active trunk repositories "thymeleaf-1.x", "thymeleaf-2.0" and "thymeleaf-2.1" into just one git repository, using different easy-to-manage branches.
What structures did we create at our git repositories?
* One branch representing the last major+minor version published snapshot: 1.1-master, 2.0-master, 2.1-master
* Branches for the development of new features in each master version: 1.1-dev, 2.0-dev, 2.1-dev
* One tag for each major+minor+bugfix version: 1.1.5, 2.0.0, 2.0.1, 2.0.2, etc.
What we think is better in GitHub compared to SourceForge.net
1. The online code browser. This is just magnificent in GitHub.
2. The branching support. Although this is more git's merit than GitHub's.
3. The code sharing capabilities: pull requests, commit exploring, linking to lines in source code, etc.
What we think is better in SourceForge.net compared to GitHub
1. The file hosting capabilities (management of downloadable files). Especially: folder support!
2. The huge amount of available tools: forums, issue tracking possibilities, diverse source code management systems, blogging, etc.
3. The web hosting features, much easier and comfortable to use than GitHub Pages.
4. The lack of a disk usage limit (300 Mbytes in GitHub! for open source projects? wtf?).
Generally speaking, as a project management tool, SourceForge.net is way better than GitHub, no doubt about that. It's been there for a lot of years, and it shows. Some features like downloadable file management, project site management, etc. clearly look as patches, as afterthoughts in GitHub (in fact, they are), even if they are extremely important for non-pet open source projects... and are aspects in which SourceForge is ages ahead.
But hey, git is just great, and GitHub is a fantastic implementation of it. We think that only it's online code browsing capabilities have made the switch worth it. Let's see if time gives us the reason.
So thanks a lot SourceForge, it's been great. We still love you.
|Free forum by Nabble||Edit this page|