[Bioperl-l] bioperl-dev or branch?

[Robert Buels]

Hilmar Lapp wrote:
> Yes, if by "highly experimental things" we are talking about 
> experimental versions of modules that already exist in either 
> bioperl-core or bioperl-dev.
 > [snip]
 > Yeah I think that's why bioperl-dev and bioperl-core need to be disjoint
 > sets. Or do you think that even in that case your scenario could be a
 > problem?

It's just the normal way to develop a new, potentially disruptive 
feature: branch, develop your feature (possibly pulling updates from the 
main branch if you feel that you need to), and then when it's far enough 
along for development to proceed on the trunk, you use your version 
control system's merging tools to merge the changes into the trunk, toss 
out your old branch, and continue your polishing on the trunk.  That's 
just the way it's usually done nowadays, with modern version control 
systems.

If the things you're doing on the branch don't overlap at all with the 
existing code from the trunk, the merge is completely clean and you're 
golden.  However, if your changes are not completely disjoint, with 
merging you have a pretty good shot of getting them in there cleanly and 
automatically, whereas if you're developing essentially outside of the 
codebase, you're going to either have to merge your changes in manually.

In the disjoint case, you're equally fine with a branch, and in the 
non-disjoint case, you are much better off with a branch.  One of the 
cases is a tie, and one is a clear win.

Trust your version control system, and use its features.

Rob

P.S. more modern version control systems make this sort of thing quite a 
bit easier than with svn, but svn's simple merge functionality is still 
better than merging changes manually.