://svnbook.red-bean.com/en/1.0/re16.html ?
Thanks,
Otis
- Original Message
From: [EMAIL PROTECTED]
To: java-commits@lucene.apache.org
Sent: Wednesday, May 31, 2006 5:58:01 PM
Subject: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt
src/jsp/results.jsp
Author: dnaber
Date
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 br
sometimes there is a 2.0.x branch that's like the trunk 2.0 fixes,
while 2.1 or future releases are being worked on in the real trunk.
that is if older releases are being maintained while new releases are
being worked on.
ray,
On 6/1/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
Otis Gospodnetic
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: java-dev@lucene.apache.org
Sent: Wednesday, May 31, 2006 8:01:13 PM
Subject: Re: svn co
On Donnerstag 01 Juni 2006 01:12, Otis Gospodnetic wrote:
> I saw this commit on trunk. Did you simply make the same change in both
> branches/lucene_2_0 and in trunk?
Yes, I copied the changes manually. I would have thought that the person
who commits can also best decide whether something sho
Just my opinion based on working with SVN with an entirely different
development model:
Trunk is production and branches are different people individual or
collaborative efforts, with one branch for maintenance changes. When
enough maintenance changes are ready for a release, we merge it into
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 exp
