YellowGrass

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

Issue Log

On 14 October 2012 at 18:29 Emmanuel Castro commented:

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.

On 15 October 2012 at 09:51 Lennart Kats commented:

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?

On 15 October 2012 at 10:19 Gabriël Konat commented:

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.

On 17 October 2012 at 09:11 Dobes Vandermeer commented:

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.

On 17 October 2012 at 10:59 Rob Vermaas commented:

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.

On 8 January 2013 at 14:04 Eelco Visser tagged major
On 8 January 2013 at 14:04 Eelco Visser tagged task
On 8 January 2013 at 14:04 Eelco Visser removed tag question
On 8 January 2013 at 14:05 Eelco Visser tagged 1.3
On 9 January 2013 at 23:38 Eelco Visser tagged !eelcovisser
On 15 January 2013 at 16:35 Vlad Vergu commented:
  • 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
On 15 January 2013 at 16:35 Vlad Vergu tagged !vvergu
On 22 July 2013 at 20:35 Vlad Vergu commented:

I think this issue is long solved; since the move to GitHub.

On 22 July 2013 at 20:35 Vlad Vergu closed this issue.
On 9 September 2013 at 11:42 Guido Wachsmuth reopened this issue.
On 9 September 2013 at 11:51 Guido Wachsmuth commented:

I reopen this issue because it is unclear how to handle unstable in the current git setup. If this is a separate issue, we can also open a new one.

Currently, unstable is outdated (even behind stable). Currently, there is no process established how to get from nightly to unstable to stable. There seems to be an implicit policy to merge only tested things to master (which corresponds to nightly currently) and develop untested features in separate branches, which are not exposed to update sites at all. This might indicate that unstable became obsolete.

Until this is solved, I removed the reference to the unstable update site from the download page.

On 27 February 2014 at 07:05 Guido Wachsmuth commented:

Unstable has its own branch again and I brought back the text on the download page.

On 27 February 2014 at 07:05 Guido Wachsmuth closed this issue.
On 27 February 2014 at 07:50 Vlad Vergu reopened this issue.
On 27 February 2014 at 07:51 Vlad Vergu commented:

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.

On 13 March 2014 at 08:55 Eelco Visser tagged 1.2
On 13 March 2014 at 08:55 Eelco Visser removed tag 1.3
On 28 July 2014 at 22:48 Gabriël Konat closed this issue.

Log in to post comments