You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Otis Gospodnetic <ot...@yahoo.com> on 2006/06/01 01:12:19 UTC
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
I saw this commit on trunk. Did you simply make the same change in both branches/lucene_2_0 and in trunk?
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 ?
Thanks,
Otis
----- Original Message ----
From: dnaber@apache.org
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: Wed May 31 14:58:01 2006
New Revision: 410680
URL: http://svn.apache.org/viewvc?rev=410680&view=rev
Log:
backport: make web application demo work again: don't use a QueryParser method that doesn't exist anymore
Modified:
lucene/java/branches/lucene_2_0/CHANGES.txt
lucene/java/branches/lucene_2_0/src/jsp/results.jsp
Modified: lucene/java/branches/lucene_2_0/CHANGES.txt
URL: http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_0/CHANGES.txt?rev=410680&r1=410679&r2=410680&view=diff
==============================================================================
--- lucene/java/branches/lucene_2_0/CHANGES.txt (original)
+++ lucene/java/branches/lucene_2_0/CHANGES.txt Wed May 31 14:58:01 2006
@@ -2,6 +2,15 @@
$Id$
+Release 2.0.1 (not yet released)
+
+Bug fixes
+
+ 1. Fixed the web application demo (built with "ant war-demo") which
+ didn't work because it used a QueryParser method that had
+ been removed (Daniel Naber)
+
+
Release 2.0.0 2005-05-26
API Changes
Modified: lucene/java/branches/lucene_2_0/src/jsp/results.jsp
URL: http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_0/src/jsp/results.jsp?rev=410680&r1=410679&r2=410680&view=diff
==============================================================================
--- lucene/java/branches/lucene_2_0/src/jsp/results.jsp (original)
+++ lucene/java/branches/lucene_2_0/src/jsp/results.jsp Wed May 31 14:58:01 2006
@@ -78,7 +78,8 @@
Analyzer analyzer = new StopAnalyzer(); //construct our usual analyzer
try {
- query = QueryParser.parse(queryString, "contents", analyzer); //parse the
+ QueryParser qp = new QueryParser("contents", analyzer);
+ query = qp.parse(queryString); //parse the
} catch (ParseException e) { //query and construct the Query
//object
//if it's just "operator error"
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Posted by Ray Tsang <sa...@gmail.com>.
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 <cu...@apache.org> wrote:
> 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt
src/jsp/results.jsp
Posted by Doug Cutting <cu...@apache.org>.
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Posted by Otis Gospodnetic <ot...@yahoo.com>.
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: java-dev@lucene.apache.org
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt
src/jsp/results.jsp
Posted by Doug Cutting <cu...@apache.org>.
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Posted by DM Smith <dm...@gmail.com>.
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
trunk, cut a tag and release the tag. Merging from trunk into
development branches occurs prior to releasing the development
branch. When it happens is at a time that is agreeable to the
developers for the branch. Most developers merge trunk into their
branch shortly after a release. In this model, all merges are in and
out of trunk and apart from merges, trunk never changes. One short
coming of this model is that the changes within a branch are not
readily visible via svn info.
Given the nature of this project, I am not recommending this model.
There are simply to few releases and the interval between them is too
long. The other nature of this project is that "developer branches"
are peoples personal work area and they check in via patches.
What I wanted to comment on was how merging behaves. I found merging
works very well provided that a change is not applied to two
different copies that are to be merged (e.g. a branch and trunk) In
this case, it will almost always produce a conflict. When using merge
to apply the changes to a copy and then merging it into trunk works
very well. When it does merge without a conflict it does it silently.
Since the merge is purely textual, it cannot determine whether the
merge preserves the semantic meaning of the code. If care is taken to
only change what is necessary, this generally works as expected. If
the code is significantly refactored and then receives a merge, it
will require careful review.
So if trunk (2.1 development) is going to diverge significantly from
the branch (2.0 maintenance), sooner or later a change won't make
sense to merge. At that point it won't make sense to merge ever
again. It may also be that a patch only applies to 2.0 and not 2.1.
So I guess, I recommend not using merge ever.
If a file has changed between the 2.1 copy and the 2.0 copy, then the
patch will probably only work on the one from which it was made. If
the changes are not too great then using a merge tool (such as the
one that comes with TortoiseSVN) after the patch is applied to the
one is easiest.
-- DM
On Jun 1, 2006, at 4:34 PM, Daniel Naber wrote:
> 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 should be
> backported.
> When someone later merges a a large amount of patches he would need to
> rely on the changelog entry or study the patch, or am I missing
> something?
>
> Regards
> Daniel
>
> --
> http://www.danielnaber.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Posted by Daniel Naber <lu...@danielnaber.de>.
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 should be backported.
When someone later merges a a large amount of patches he would need to
rely on the changelog entry or study the patch, or am I missing something?
Regards
Daniel
--
http://www.danielnaber.de
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org