Hi all,
Bert already mentioned that I've been working on migrating the repository from SVN to Git. I believe there are three problems that need to be solved here:
*1. Migrating SVN externals for sharing code between branches* This is currently used to share a few directories (e.g. platforms/Cross/plugins) across different branches. But Git does no support this kind of code sharing. Instead, it supports submodules [1] and subtrees [2]. I would suggest to move code that we want to share into separate Git repositories and include them as submodules. I think submodules are easier to understand (GitHub integrates them nicely in their UI). The only drawback: if someone updates code in a shared repository, one needs to update all references to this repository as well. But I'd say this is also a good thing: if someone changes e.g. a plugin and the change is compatible to Cog, but incompatible to the interpreter vm, then the interpreter branch is not automatically broken as soon as one pushes the plugin change. If the above is unclear, I'm happy to explain submodules in more detail.
*2. Versioning and new releases* If we migrate to Git, I'd recommend to deprecate the way we do versioning in SVN. Instead, we should use Git commit hashes and Git tags. Let's say we want to release a new version, we tag the commit of interest with e.g. v1.0.0. When building the Cog VM on this tag, the version will be v1.0.0. If we use GitHub, we might as well use a CI service such as Travis CI [3] to automate the build process. That means, each time someone pushes changes to GitHub, Travis CI will build a new Cog VM (we can call this "bleeding edge"). Let's say I push changes right after the release of v1.0.0, the version for the next build will be something like v1.0.0-37553a9 with "37553a9" being the short SHA1 identifying my latest commit. If we want to release e.g. v1.1.0, we just tag a newer commit and GitHub/Travis CI does the rest for us. I already have this working, you can find a Travis build at [4] and the result at [5]. Obviously, we can push the binaries to a different server.
*3. Keeping a copy of the code* We of course want to keep a copy of our code at all times in case something happens with GitHub. There are already tools that we can use to automate this. However, I wouldn't try to keep the old SVN repository in sync. I believe this might be quite difficult and I don't see a reason to maintain something we want to deprecate in the first place. Anyway, it should be fairly easy to set up a tool that creates a backup on one of our servers whenever we change code on GitHub.
Doing a migration from SVN to Git(Hub) takes a few hours and I'd recommend we stop pushing code to the SVN as soon as we start to migrate. This obviously requires everyone working with the code base to switch to Git. So please let me know if everyone is comfortable with the migration. If we want to do this next week, I'd recommend to do it on a Thursday or a Friday, because I would be able to do it with Bert sitting two rooms next to me :)
I hope I have thought about the important things and I'm happy to answer any questions you might have.
Best, Fabio
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules [2] http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree... [3] http://travis-ci.org [4] https://travis-ci.org/fniephaus/squeak/builds/119507180 [5] https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/