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 earlier? $ 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".
Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
