<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Rob,<br><br>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). <div><br></div><div>Branching code is very useful but it isn't always the best solution.<br><div><div><br>chris<br><br>On May 21, 2009, at 10:44 PM, Robert Buels wrote:<br><br><blockquote type="cite">Hilmar Lapp wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Yes, if by "highly experimental things" we are talking about experimental versions of modules that already exist in either bioperl-core or bioperl-dev.<br></blockquote></blockquote><blockquote type="cite">> [snip]<br></blockquote><blockquote type="cite">> Yeah I think that's why bioperl-dev and bioperl-core need to be disjoint<br></blockquote><blockquote type="cite">> sets. Or do you think that even in that case your scenario could be a<br></blockquote><blockquote type="cite">> problem?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Trust your version control system, and use its features.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Rob<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Bioperl-l mailing list<br></blockquote><blockquote type="cite">Bioperl-l@lists.open-bio.org<br></blockquote><blockquote type="cite">http://lists.open-bio.org/mailman/listinfo/bioperl-l<br></blockquote><br></div></div></div></body></html>