Sorry for newbie questions. I'm at home with CVS branches, merging, etc., but not so with SVN. 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? It sounds like you are describing "selective patching" of the release in the branch with diffs between 2 specific revisions in the trunk. Is that it? 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 Thanks, Otis ----- Original Message ---- From: Doug Cutting To: [email protected] Sent: Wednesday, May 31, 2006 8:01:13 PM Subject: Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp Otis Gospodnetic wrote: > How should 2.0 fixes be handled? Should we fix things in branches/lucene_2_0 > and then manually apply the same change to trunk immediately, or are people > using svn merge a la http://svnbook.red-bean.com/en/1.0/re16.html ? Generally we should not change things in the branch, but rather continue to develop primarily in trunk, then sync applicable patches to the release branch with 'svn merge' when we're preparing to make a point release, including the revision range merged in the commit message. This makes it much easier to determine which patches have been sync'd to the release branch and which have not. Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
