Table of Contents
Plans for migration to Git
We plan to migrate from Subversion to Git, but we are going to delay this change (see the reasons at the end of this page). The following tasks are to be done:
Removing auxiliary binary files from the trunk and put into somewhere else
The auxiliary files are usually written by 3rd party developers. These are used for compiling GeoGebra, creating the installer or just for runtime use. Our general rule is that we don't want to include 3rd party software for the GeoGebra trunk, but we also do not want to harden the workflow process for our developers. That means that we created two data stores: one for the GeoGebra source and one for the 3rd party software. Now we offer a Git repository and an ANT script which downloads all required 3rd party packages from various internet datastores. For ensuring availability, we also offer http://www.geogebra.org/download/lib (and http://www.geogebra.org/download/installer).
The migration has been done in two steps. First, all binary files (including *.jars) were moved to the lib/ directory. lib/build/ contained all binaries that are necessary for building GeoGebra, installer/ was for those binaries that can create the installer. The remaining files from lib/ were needed for the runtime use of GeoGebra. The second step was to remove the binary files and making it possible to download them by using an ANT script.
At the state of writing this, some beautifying are still to be done. E.g. MPReduce default.img could be generated by a script. Zoltan and Thomas (and Ted) are working on these issues.
Unmodified 3rd party sources
We use some external libraries with their source, without any changes. For example, MPReduce is such a library. (A complete list is needed here.) A possible solution for not storing the sources for these libraries (but use their original version) is to use the "git submodule" (http://book.git-scm.com/5_submodules.html). Gabor was thinking on how to do this, but it is not really straightforward what is the best solution.
Git repositories
There was quite a big discussion about where to host the git repositories. Git geeks mostly voted to use GitHub as the primary place, some others (including Zoltan and Markus) voted to have an own repository instead.
The first attempts were done in private clones of the SVN repository by several people. Some people already also set up mirrors for GeoGebra on GitHub (e.g. https://github.com/jumpa/geogebra) for testing. Ralf Hemmecke also created a (maybe temporary) web page for recording the issues concerning the change at https://issues.risc.jku.at/geogebra/. (This separate place is mostly to avoid spamming the geogebra-dev list by technical questions.)
On 2011-10-06 Ralf and Zoltan successfully set up an official GitHub mirror here:
The first one is refreshed in every hour from the official SVN repository from Luxembourg (done by the Linz development server). The second one contains all the history before revision 13007. It seems this will be the best solution because the .git folder (which contains all previous version) is about 180 MB for geogebra-old. This is still too much for most developers to download. (If we remove some "unneeded" files, including *.exe, *.jar, *.dll, *.so, *.jnilib, */regression/tests/*, the .git folder is still about 130 MB.)
Now when cloning the geogebra repositories from GitHub, the .git directory (which is about to download) only 11 MB and after decompressing we get an extra 50 MB for the current source code (but this step is purely done on the client machine, no web connection is needed). If someone needs investigating the code before revision 13007, then he needs to download the geogebra-old directory from GitHub. It will take several minutes. After that, some small configuration tweak is needed to link the two repositories together. Detailed information is provided by Ralf at https://sites.google.com/site/hemmecke/geogebra-svn#include-the-history.
Workflow changes
Simultaneously, Eclipse plugins are to be searched to substitute Subversion (Gabor). Egit seems to be a working way. Trac must also be reconfigured (Yves, Zoltan).
Julian suggested to use https://github.com/davglass/github-trac/ for integrating GitHub into trac. We will try it (maybe also in Luxembourg).
While everything is set up and tested properly, the developers must be notified about the changes. For this Zoltan and Gabor are responsible.
Delaying the change
Finally we decided to delay the change due to the following reasons:
- Trac/Git is not so mature for the everyday use like Trac/Subversion is. Ticket integration with internal links to revisions does not seem to be implemented for any of the TracGit forks.
- Subversion is indeed capable of moving files with history, but the Eclipse/Subversive plugin is not. To resolve this problem, we suggest using Eclipse/Subclipse instead of changing the whole workflow to Git.
- Learning Git requires a new kind of attitude and some time. The main programmer crew is really relying on many convenient services of Trac/Subversion which are too many as to be substituted within a short time. Maybe some Python programming would also be required to implement every nuisance we like in Trac/Subversion.
- Trac/Subversion seems to be much faster than Trac/Git on the same machine. Trac/Subversion will be significantly faster by using the Linz server when we will move the whole Trac database, so the speed issues will disappear.
- Setting up Trac/Git with the basic features is not so easy as we thought. We need more time to set up a good enough server, but we should focus on more important subprojects first.
- The GitHub mirror can help those developers who really want to change to Git. They can also use Ralf Hemmecke's hints on how to push their copy back to the official Subversion repository. (A short guide should be written for this if Ralf's hints are not straightforward. Gabor?)
So... When do we plan to migrate?
- Please monitor https://github.com/hvr/trac-git-plugin/network. This will immediately show when a major change is done on Trac/Git.
- If someone is interested in Python coding, any help is welcome. (Arnaud?)
