[Biopython-dev] SVN migration and Launchpad mirroring

[Bruce Southey]

Eric Talevich wrote:
> Mark Shuttleworth blogged about why Ubuntu chose bzr awhile back:
>
> * "Choose lossless VCS tools if you have that luxury" --
> http://www.markshuttleworth.com/archives/125
>
> * "Merging is the key to software developer collaboration" --
> http://www.markshuttleworth.com/archives/126
>   
(Yeah but I am not a fan of his writing.)
Python PEP 0374 "Migrating from svn to a distributed VCS" makes some points.
http://www.python.org/dev/peps/pep-0374/

> The use case for DVCS is what I assume usually happens when a new parser or
> other module is added to Biopython -- an outside developer has some sizeable
> chunk of useful code and needs to integrate it with the trunk. "Code bombs"
> are something the Linux kernel deals with constantly; I have no idea how
> they'd deal with it in a centralized system. (Nobody does; they never did
> use cvs.)
>   
They complain rather loudly!
Really there is a development process that tries to avoid this 
especially the 'release early, release often' adage. Hopefully this 
should not happen with Biopython...

> My lab uses bzr now. I have it set up to work like a centralized repository
> in general; I'm the only one who uses the distributed features at the
> moment, switching between a laptop and a workstation. The merging and
> renaming support is much better than svn's, and it was easier to set up. It
> feels kind of crazy to me now to add a significant new change to a project's
> trunk in one monolithic commit, and I feel the pain of any maintaner who has
> to apply a patch set to the trunk after the developer's branch and the trunk
> have diverged.
>   
How do you avoid this pain?
>
> Regarding other concerns:
>
> - For update operations more advanced than just pulling the latest revision
> from the trunk, in bzr et al., it's possible to cherry-pick specific
> revisions from other developers.
>   
But that requires some degree of advanced knowledge.
How easy is it to revert a revision, especially down the road?
> - Similarly, it's possible to only merge completed bug fixes and
> enhancements to the trunk, skipping any new/unstable work a developer has
> embarked on in their branch. That's why Linux is now permanently on version
> 2.6.X -- basically every commit can be made stable, so there's no need for a
> new unstable series in the trunk.
>   
I do not agree here because the Linux kernel process doesn't work that 
way see Corbet's take: 
http://ldn.linuxfoundation.org/book/how-participate-linux-community
You have the very frequent merge windows with a testing period, the new 
staging tree, the -mm tree, and a solid team of 'lieutenants' that 
reduce many of the problems. In addition, you have the stable tree for 
major bugs.

Would Biopython need to do something similar like having a merge windows 
and a stable tree?
> - Testers should enjoy the ability to pull specific changes while ignoring
> unrelated code, even in the same file -- the distributed systems all have
> this capability (shelve).
>   
Again requires some advanced knowledge. But I am not sure how much time 
do I would want to waste on doing that if it does not lead to some thing 
being included in the main branch compared to code that does enter the 
main branch. (Yes, it is somewhat selfish.)
> - PPAs are less useful for Python packages; they just let you manage
> everything from apt instead of easy_install. I use a PPA to keep my lab's
> machines on the same version of bzr despite having different versions of
> Ubuntu. I don't use easy_install for anything right now because it scares
> me.
>
>   
I know but I don't use either (nor any rpm-based system for that matter)!
> Best,
> Eric
Bruce