[Bioperl-l] bioperl-dev or branch?
rmb32 at cornell.edu
Thu May 21 23:44:23 EDT 2009
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.
> 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
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
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.
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.
More information about the Bioperl-l