[Bioperl-l] BioPerl Migration to Git/GitHub

Heikki Lehvaslaiho heikki.lehvaslaiho at gmail.com
Thu May 6 17:26:48 UTC 2010

On 5 May 2010 17:46, Chris Fields <cjfields at illinois.edu> wrote:

> 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).

Do not worry about those, I'll move them into the final repo once it is
there. I am just making sure everything works.

> 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
Keep it. It does no harm.

> 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...

Let's go for github as the main repo. It adds visibility and has the
coolness factor that helps.

> 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

Lets try to follow this strategy. I do not think moving away from svn and
going decentralized at one go would work at all.

> 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.

I would not worry too much about that. With git we'll have dozens if not not
hundreds of full copies of the repo as a backup.

> 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

Interesting and educational document. Let's learn as much a we can from it.

This is easy with github and forks.

The more the merrier.

BTW, I can see Moose using Shipit,
that might be worth using in BioPerl.

> 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?

Why not is someone insists on using it. Once people get over the initial
problems of moving to a different mind set in git, very few will want to use
svn. There might be situtations when git does not work, however, so lets
allow for svn usage.

> 7) Others?
> chris
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l

More information about the Bioperl-l mailing list