Move to github (2)
Have you considered hosting the project on github instead of your own subversion repository?
Github has a great workflow for submitting patches as pull requests. Git is great for open source projects because one can do “local commits” and merges without needing write access to the repository. Subversion’s branch/merge support is a pain.
Their bug tracker isn’t great, but comparable to YellowGrass.
There’s a very nice continuous integration thing called Travis CI that will auto-build and test all your branches and pull requests.
Something to think about …Submitted by Dobes Vandermeer on 13 October 2012 at 19:32
We have two things to think about:
- Git or Mercurial (hg)? And consequently GitHub or BitBucket? IMHO, Git is fashion, and Mercurial is stable and it provides a standard GUI for both Linux, Mac and Windows.
- Both Git and Mercurial fail to store empty directories. Failing to set them up brakes the Spoofax build process. One can circumvent it by adding .empty files where needed.
Mercurial has a plugin named hgsubversion which let you pull the history from a svn repository. What prevented me using it, was the empty directory problem.
There are plans to move to git and github and some point. Thanks for the empty directory suggestion. It really shouldn’t break because of missing empty directories, though. Which directories are those, exactly?
We’re probably going to move to git somewhere in November or December.
There still is the choice between github and bitbucket. Bitbucket has free organization accounts (http://blog.bitbucket.org/2012/08/20/bitbucket-academic/) with private repositories for academical institutes. Github seems to have something similar (https://github.com/edu) but we’d probably only get a discount.
I prefer the interface and openness of github over bitbucket, although bitbucket did improve their UI a lot last week.
It’s also possible to put all the opensource stuff on github and have closed repositories on bitbucket, although it’s more convenient to have them at one place.
As for doing the conversion from SVN to git, an idea would be to just convert the entire StrategoXT repository to git (locally), and use https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo to split relevant projects into their own repositories. These can then be pushed to remote repositories on github/bitbucket.
If there’s a vote to be had, I’d vote for github since it’s more familiar to me. I’ve never used mercurial. I think git has better support from the IDEs.
We have done already quite a bit of migration to git for the Nix project, and we used a tool developed by the KDE team to perform their conversion http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
This tool support splitting repositories, based on subdirectories. The Nix repo had the same kind of structure as the StrategoXT repository had.
A problem with creating git/mercurial repositories for Spoofax is probably that Spoofax consists of many components all living in separate SCM locations.
- Stratego/XT and Stratego/XT-Java projects are now located at GitHub (https://github.com/metaborg/strategoxt)
- New commits to old repository (SVN) will not migrated, code bases kept for historical reasons only
- Hydra (buildfarm) jobs are being updated as we speak
I think this issue is long solved; since the move to GitHub.
I reopen this issue because it is unclear how to handle
unstablein the current git setup. If this is a separate issue, we can also open a new one.
unstableis outdated (even behind
stable). Currently, there is no process established how to get from
stable. There seems to be an implicit policy to merge only tested things to
master(which corresponds to
nightlycurrently) and develop untested features in separate branches, which are not exposed to update sites at all. This might indicate that
Until this is solved, I removed the reference to the unstable update site from the download page.
Unstable has its own branch again and I brought back the text on the download page.
Coming Wednesday (5/4/14) @Gabriel and I will work out a deployment process more suited to our development on GitHub. We’ll also create a GitHub repo purely for orchestration of deployments across multiple Git repositories.
Log in to post comments