[Bioperl-l] BioPerl Migration to Git/GitHub

[Chris Fields]

All,

I would like to finalize moving over to git/github very soon.  We're sort of in limbo on this, so it needs to progress forward.  We'll need to do some initial cleanup after the move (Heikki is already doing a few things on the test repo, which we'll need to diff over to the new one).  

So with that in mind, here are my thoughts.  This is copied over to this wiki page, in case you don't want to reply here:

http://www.bioperl.org/wiki/From_SVN_to_Git

(thanks Mark!)

1) Timeline

When?  Sooner the better (weeks as opposed to months).  Our anon. svn is down, likely permanently (http://code.open-bio.org/svnweb/index.cgi/bioperl/browse/bioperl-live).  

2) Migration strategy

Now mainly worked out using svn2git, which is very fast.  We would need to make the svn repo on dev read-only during this transition.  My guess is it would take very little time.  Do we want to retain the git-SVN metadata on commits?  This is viewable with our current read-only mirror on github:

http://github.com/bioperl/bioperl-live/commit/7090e24f3916346b11a6bf960371f1d903d241ca

3) Developers

Not everyone has a github account.  Recent ones who I couldn't find on github: dmessina, fangly

The current authors file used for mapping commit authors to emails used their respective bioperl.org addresses (DEVNAME -at- bioperl.org).  I think, once one has signed up with github, you can add that same address to your current ones, and it should map to your github account.  If we use dev.open-bio.org as our central git repo, we won't need to go through with that, but we will need a viewable version of dev available somehow (mirrored on github or otherwise).  Speaking of...

4) Development strategy

Are we sticking with a single centralized repo (SVN-like)?  Will that be github, or will github be a downstream repo to our work on dev?  We could feasibly have github be an active, forkable repo that could be bidirectionally synced with dev, but I'm not sure of the logistics on this (this popped up before with svn migration and was rejected b/c it was considered too difficult to maintain).

Git makes it very easy to make branches and merge in code to trunk.  With that in mind, I would highly suggest we start working on branches for almost everything and merge over to trunk.  There is very little to no overhead in doing so with git.

I like this strategy (Mark Jensen pointed this out): http://nvie.com/git-model

Also, several points were raised in a related project (Parrot) considering a move to git/github from svn.  One in particular was that git allows destructive commits.  Jonathan Leto indicated we can set up specific branches that don't allow this, using commit hooks, so my guess is the master branch and release branches wouldn't allow rewinds.

5) Encouraging outside contributors

Do we want to adopt a policy similar to Moose?

http://search.cpan.org/dist/Moose/lib/Moose/Manual/Contributing.pod

This is easy with github and forks.

6) SVN Read/Write to GitHub

It was recently announced that one can access a github repo using subversion as read-only, and just yesterday experimental write to github is allowed:

http://github.com/blog/644-subversion-write-support

I can see allowing read-only svn, but write support is still experimental.  Do we want to allow that?

7) Others?


chris