[Biopython-dev] SVN migration and Launchpad mirroring

[Bruce Southey]

Bartek Wilczynski wrote:
> Hi,
>
> On Tue, Feb 10, 2009 at 2:26 PM, Peter <biopython at maubp.freeserve.co.uk> wrote:
>   
>>> I've taken the whole biopython CVS tree with complete version history
>>> (~3500 commits) and converted it to bzr branch using tailor. It took
>>> about 2-3 hours, but it needs to be done only once.
>>>       
>> Did you do that from the public Biopython CVS server to your machine?
>> If so, its nice to know that step isn't too slow.
>>
>>     
> You can do it using any cvs repository, but doing it over the network
> slows it down.
>  I got bored so I downloaded the actual CVS repo from
> dev.open-bio.org:/home/repository/biopython
> The 2-3 hours is  for conversion from a local repository which was a
> copy of the
> original biopython one. But once it is done you have a directory tree
> which has both
> CVS and .bzr entries, so you can use it for synchronization.
>
>
>   
>> Have you got a feel for whether it would be easier to sync CVS and
>> bzr, or SVN and bzr?
>>
>>     
> The tool I used (tailor) works with all VCS systems out there. Also launchpad
> is able to update a branch form either cvs or svn main repository. So
> there should be
> no difference, apart from one migration (CVS->SVN) more.
>
>   
>> I personally would be more interested in an automatically synchronized
>> git repository (rather than bzr), but this is not a thoroughly
>> researched opinion.  As you pointed out, the poor bzr benchmark speeds
>> may not be so bad in the latest code - although the Biopython code
>> base is not so big that this really matters.
>>
>>     
>
> when it comes to git, I have to say that I'm not really experienced,
> but my current understanding of
> the possibilities is as follows:
> I don't know about any service to _automaticaly_ synchronize CVS (or
> SVN) repo with git.
> There is git-svn, so if we move to SVN, we can set up a git repository
> and write some scripts
> around git-svn to have it synchronized with SVN trunk. Then, if we
> want to host it,
> we need to start a git-server on dev.open-bio.org or use the free
> account on github. It has a limit of
> 100mb and current biopython CVS tree is 57Mb, so we can go with it for
> a while, but I'm not sure if
> I would recommend it.
>
> But for sure there are people more experienced with git than me on the
> list, so we may hear about better options.
>
> cheers
> Bartek
>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>   
Hi,
Thanks for doing all of this as it is very very interesting work!

I am not experienced in either nor do I have a preference. But I 
appreciate the various comments on this as it makes it clear that 
Biopython needs to go to one of these systems.

I came across various blogs that show the newest versions are bzr are 
much faster than the old versions. So nothing like good old competition! 
Here is one link via Google that shows various actions between git and 
bzr (a link to a similar comparison between git, bzr and Mercurial is at 
the bottom of that link):
http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/

There are options to convert between bzr and git (like tailor as well as 
plugins). Also bzr-svn 
(http://bazaar-vcs.org/BzrForeignBranches/Subversion) and git-svn 
(http://www.kernel.org/pub/software/scm/git/docs/git-svn.html ) allow 
you to connect directly to Subversion repositories. From my brief 
reading, I think these are (or meant to be) bidirectional but the cvs 
support is somewhat limited.

Echoing Chris's comment, should we even bother with svn at all?
Obviously going to git or bzr or hg, svn is not necessary but in the 
short term it could used as a transition towards one of these. Possible 
uses of the svn would be maintaining the official repository of the 
current release plus important bug fixes, a sort of staging tree that 
all new code should build against.

Bruce