You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by ry...@apache.org on 2008/10/07 01:48:29 UTC
svn commit: r702305 -
/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
Author: ryan
Date: Mon Oct 6 16:48:29 2008
New Revision: 702305
URL: http://svn.apache.org/viewvc?rev=702305&view=rev
Log:
SOLR-802 -- fix & => && in facet component
Modified:
lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
Modified: lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
URL: http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java?rev=702305&r1=702304&r2=702305&view=diff
==============================================================================
--- lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java (original)
+++ lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java Mon Oct 6 16:48:29 2008
@@ -100,7 +100,8 @@
// scalability.
for (ShardRequest sreq : rb.outgoing) {
if ((sreq.purpose & ShardRequest.PURPOSE_GET_FIELDS)!=0
- && sreq.shards != null & sreq.shards.length==1
+ && sreq.shards != null
+ && sreq.shards.length==1
&& sreq.shards[0].equals(shard))
{
refine = sreq;
Re: svn commit: r702305 - /lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
Posted by Ryan McKinley <ry...@gmail.com>.
On Oct 6, 2008, at 8:02 PM, Chris Hostetter wrote:
>
> : How do we do CHANGES.txt on the 1.3 branch?
>
> Add a 1.3.1 section on both the trunk (below 1.4) and the branch, keep
> them in sync.
>
> FWIW: The method Doug (i think it was Doug) recommend for dealing with
> point releases once upon a time (on Lucene-Java) was to commit all bug
> fixed to the trunk, mark the bug fixed in Jira, and if you thought it
> warranted a point release indicate that in Jira using the "Fix
> Version" --
> but hold off on commiting anything to the branch until a decisison
> is made
> to actually do a point release -- then use search the "Fix Version"
> for
> issues and merge their specific commits onto the branch.
>
> the theory is that merging many things to the branch is easier to do
> at
> one time then in individual merges, and you'reless likely to run into
> problems if an initial bug fix turned out to have it's own bugs.
>
> Plus you don't waste a lot of work if it turns out the point release
> never
> actaully happens.
>
that makes sense -- and easier to deal with!
For 1.3.1 I think there are already other patches on the branch, so
best if we continue with that and take the lesson for next time....
(if there are not changes, then we should just just revert to the
tagged branch)
We still need to add the existing changes to CHANGES.txt -- i don't
have time to dig around now to see what they are, so If you added
something to 1.3 post release, then go ahead and update CHANGES.txt
ryan
Re: svn commit: r702305 -
/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
Posted by Chris Hostetter <ho...@fucit.org>.
: How do we do CHANGES.txt on the 1.3 branch?
Add a 1.3.1 section on both the trunk (below 1.4) and the branch, keep
them in sync.
FWIW: The method Doug (i think it was Doug) recommend for dealing with
point releases once upon a time (on Lucene-Java) was to commit all bug
fixed to the trunk, mark the bug fixed in Jira, and if you thought it
warranted a point release indicate that in Jira using the "Fix Version" --
but hold off on commiting anything to the branch until a decisison is made
to actually do a point release -- then use search the "Fix Version" for
issues and merge their specific commits onto the branch.
the theory is that merging many things to the branch is easier to do at
one time then in individual merges, and you'reless likely to run into
problems if an initial bug fix turned out to have it's own bugs.
Plus you don't waste a lot of work if it turns out the point release never
actaully happens.
-Hoss
Re: svn commit: r702305 - /lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java
Posted by Ryan McKinley <ry...@gmail.com>.
How do we do CHANGES.txt on the 1.3 branch?
should we change the CHANGES.txt file so the top is for release 1.3.1?
If nothing else, a 1.3.1 release is warranted after the official
lucene release...
ryan
On Oct 6, 2008, at 7:48 PM, ryan@apache.org wrote:
> Author: ryan
> Date: Mon Oct 6 16:48:29 2008
> New Revision: 702305
>
> URL: http://svn.apache.org/viewvc?rev=702305&view=rev
> Log:
> SOLR-802 -- fix & => && in facet component
>
> Modified:
> lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/
> component/FacetComponent.java
>
> Modified: lucene/solr/branches/branch-1.3/src/java/org/apache/solr/
> handler/component/FacetComponent.java
> URL: http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java?rev=702305&r1=702304&r2=702305&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/
> component/FacetComponent.java (original)
> +++ lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/
> component/FacetComponent.java Mon Oct 6 16:48:29 2008
> @@ -100,7 +100,8 @@
> // scalability.
> for (ShardRequest sreq : rb.outgoing) {
> if ((sreq.purpose & ShardRequest.PURPOSE_GET_FIELDS)!=0
> - && sreq.shards != null & sreq.shards.length==1
> + && sreq.shards != null
> + && sreq.shards.length==1
> && sreq.shards[0].equals(shard))
> {
> refine = sreq;
>
>