[Bioperl-l] bioperl-dev or branch?

[Robert Buels]

Mark A. Jensen wrote:
> Maybe the solution here is what you cjf have been suggesting lately, that
> the trunk is your friend, and that frequent and fearless branching+merging
> needs to become part of the Modern BioPerl Way.

Never any need for fear when you have version control.  Once it's in the 
repository, everything is completely reversible, completely recoverable.

Actually, junk lying around a developer's working copy is the most 
frequent source of pain.  For example, somebody moves a dir in the 
repository, you update your working copy, and your uncommitted changes 
are attempting to sit on top of something somebody else has moved out 
from under you, and you have to move your local changes out of the way 
and then put them back in the right (new) place, and it's a pain.

A couple of techniques for avoiding things like this:

1.) As much as possible, try to keep your working copy clean and make 
your commits both small and atomic, meaning each commit you make should 
strive to be a self-contained change that works and stands alone.  This 
is especially important if you are working on the trunk, where changes 
might be coming in often and some of them could be major.  I find it 
useful to run 'svn diff' on the set of changes I'm about to commit, to 
make sure they make sense in and of themselves.  Also, by following this 
rule, not only do you avoid problems in your working copy but you also 
help ensure that the svn HEAD is not very broken at any given time.

2.) If you find it increasingly hard to satisfy rule 1, that is a good 
indication that you are making a lot of changes, and should be working 
on a branch.  If you get to the point where you realize this and have 
heretofore managed to follow rule 1, then you can actually just make 
yourself a branch and switch to it right to your own branch right then 
and there, even with your uncommitted changes still in your working copy:

svn cp svn+ssh://.../trunk svn+ssh://.../branches/mybrokenstuff
svn switch svn+ssh://.../branches/mybrokenstuff

and poof, there you are, you are now sitting on a checkout of that 
branch, and the changes that you have sitting in your working copy are 
still there, and you can commit whatever you want, and it won't affect 
anybody else.  You should still strive to hew to rule 1 though, it just 
makes things nicer all around.

"But what about when you have to merge your stuff back into trunk?" You 
say?  People sometimes make rather too much of 'the difficulty of 
merging back into trunk'.  If you are working on different things from 
other people, the merge is likely to come off without a hitch.  If there 
are conflicts, they are usually minor textual differences that can be 
resolved easily.  If two developers are actually working on the same 
thing, they should probably be on the same branch, or at least merge 
their work into one of their branches before merging that one back into 
trunk.

All this branching and merging is a little more cumbersome with svn than 
with more recent tools, though, because only the very latest versions of 
svn (1.5 and above I think) actually have support for tracking exactly 
which revisions of a branch need to be merged at any given time. 
Because of this, if you're doing a big long-lived branch in which you 
are tracking changes from the trunk (the most common case), or 
periodically sending changes to the trunk and keeping the branch, or 
both, it's a good idea to use an additional tool to help track exactly 
which revisions you have already merged in each direction, like 
svnmerge.py, svk, or git + git-svn (listed in increasing order of 
sophistication).  I've only ever used svnmerge.py, cause I'm still a 
relatively new at this version control stuff.  I'm working on learning 
git and git-svn though.  :-)

Rob