lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Date Fri, 02 Jun 2006 17:02:46 GMT
Otis Gospodnetic wrote:
> Developing mainly in trunk makes sense.  However, I don't get trunk -> branch to make
a point release.  What if there are other changes already in the trunk (e.g. new features),
which we don't want in a point release? 

That makes it harder!  But the common case, in my experience, is that 
shortly after a release is made, the vast majority of changes to trunk 
are bug fixes that should be merged to the just-released branch for a .1 
release.  After the .1 release, we usually don't make a lot of patches 
to release branches, and can probably make these on a case-by-case 
basis.  But for .1 releases (and there is almost always a .1 release) 
it's usually easier to keep track of which patches have been made if 
they're separately merged to the release branch from trunk, rather than 
directly committed to the release branch, and if fewer such merges are 
made rather than more.  So, given the above, my original statement 
should make more sense: developers should generally commit patches to 
trunk, and let someone who's building a patch release worry about 
merging them to the branch.

There are of course exceptions.  Some patches may need to be very 
different in a release branch than in the trunk, and are best made by 
the same person who makes the patch to the trunk, someone who has a 
detailed understanding of the patch.  But these are the exception.

It's good to keep track of which patches have been merged to a release 
branch and which have not.  Thus patches should always be merged from 
trunk to release branches in a separate commit that names the revision 
range that's merged in the commit message.  Fewer such merges simplifies 
things.  If there are a sequence of patches, all of which should make it 
to the release branch, as is common with .1 releases, the most common 
type of point release, then one can minimize the number of merges by 
merging later rather than sooner.

> Considering trunk is currently at revision 410747, what should N and M be for something
that we want to patch in the branch (trunk->branch), such as that JSP fix that Daniel made
> $ svn merge -r N:M src/jsp/results.jsp

The correct N and M can be tricky to get right.  I usually use 'svn log' 
and/or my commit mail archive to figure it out.  The more merges we do, 
the trickier it gets.  Also, you also need to always follow this with:

svn commit -m "merge -r N:M  Merging patches XXX, YYY and ZZZ to release 
A.B branch."

So that folks can later figure out what's been merged and what hasn't. 
It's also good to track this in Jira, using the "Fix Version".


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message