I would agree with Peter's points about git and decentralization.  This feature of git makes any instability in a web host nearly moot.  The only caveat is that issue tracking is done outside of the git repository, so you could lose<span></span> interesting secondary material if a particular service were to shut down.<div>
<br></div><div>For example, I have a mirror of one of my code repositories in two different github accounts:</div><div>     <a href="https://github.com/craigsapp/humextra">https://github.com/craigsapp/humextra</a></div><div>
and</div><div>     <a href="https://github.com/humdrum-tools/humextra">https://github.com/humdrum-tools/humextra</a></div><div><br></div><div>These are identical repositories (not an original and a fork).  To update I run these commands:</div>
<div><br></div><div>git push origin craigsapp</div><div>git push origin humdrum-tools</div><div><br></div><div>with these two origins set up in the git config file.  I disable issue tracking in the second repository so that they remain all in one place.</div>
<div><br></div><div>This system should work well for Mei repositories.  The google code repository would be converted to git (assuming that the issue tracker would not be lost).  Then a duplicate copy of the repository would be placed on GitHub (or bitbucket, etc.) with the only difference being that the issue tracker would be disabled and a pointer given to google code if someone wants to report bugs or ask for new features.</div>
<div><br></div><div>-=+Craig</div><div><br>On Friday, July 4, 2014, Peter Stadler <<a href="mailto:stadler@edirom.de">stadler@edirom.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I’d say this is actually an argument in favor of Git(Hub) ;-)<br>
Google is known to remove or change (even successful) services at will, so to me it seems more save to move to a hoster who’s sole purpose is code repository management.<br>
That said, you can never be 100% sure relying on free (or even paid) services but moving to Git (not GitHub now) will make the whole setup more robust since every clone carries the complete history while svn working copies are dumb and can do almost nothing without a server connection (svn = centralized, git = decentralized).<br>

<br>
Best<br>
Peter<br>
<br>
Am 03.07.2014 um 15:35 schrieb Urs Liska <<a href="javascript:;" onclick="_e(event, 'cvml', 'ul@openlilylib.org')">ul@openlilylib.org</a>>:<br>
<br>
> Joining the party late ...<br>
><br>
> I am referring to this thread:<br>
> <a href="https://lists.uni-paderborn.de/pipermail/mei-l/2014/001244.html" target="_blank">https://lists.uni-paderborn.de/pipermail/mei-l/2014/001244.html</a><br>
><br>
> I don't know if there has been a decision in the meantime and how it turned out in the end, but I wanted to point to a intense discussion we had about moving LilyPond's source code to Github.<br>
><br>
> While most people agree that Github's interface and collaborative possibilities are awesome (apart from a few people who actually prefer exchanging patches via email) it was pointed out that Github's Terms of Service are questionable when it comes to Free or Open Source software. In particular they reserve the right to close their free services or restrict access to projects or revoke contracts at will and at any time.<br>

><br>
> Although I personally use Github very much I think these are issues that should be considered for a project of MEI's intent.<br>
><br>
> Best regards<br>
> Urs Liska<br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'mei-l@lists.uni-paderborn.de')">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</blockquote></div>