[Bioperl-l] bioperl-dev or branch?
cjfields at illinois.edu
Fri May 22 12:55:18 UTC 2009
We trust our vcs. I do wish others would use branches more often, but
that's not the problem I'm worried about. Core is simply bloated with
unmaintained (albeit possibly useful) code. This isn't a simple issue
that can be sorted out with branches, excepting that we can use them
to work on sorting out the code into the various repos. Tons of
larger projects have split their code into more maintainable smaller
bits, similar to our proposed layout. They're simply easier to
maintain as separate projects within an overarching repo (bioperl).
Branching code is very useful but it isn't always the best solution.
On May 21, 2009, at 10:44 PM, Robert Buels wrote:
> 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
> > 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.
> 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.
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
More information about the Bioperl-l