FYI JIRA issue & PR: https://issues.apache.org/jira/browse/SOLR-16693
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Mar 7, 2023 at 11:15 AM David Smiley wrote:
>
> On Tue, Mar 7, 2023 at 10:44 AM Houston Putman wrote:
>
>> The only issue I
On 3/10/23 06:49, Kevin Risden wrote:
So in the case of https://github.com/apache/solr/pull/571 that would be
concretely:
git fetch origin pull/571/head:pr-571
git checkout pr-571
This would work if https://github.com/apache/solr is cloned. There should
be no need to try to find a merge base
Disclaimer: technical details that aren't strictly about Solr coming up ahead:
Crave builds and tests the Solr code on a remote server.
The first step to doing that is to "clone the exact sources on the remote
system".
A brute-force way to do that would be rsync the sources from the Github
I kind of like "Aggregation API" (or something similar).
Facets/stats/analytics are all definitely "aggregations". As luck
would have it, "aggregation" isn't yet used to mean something more
specific in Solr (right?), so we wouldn't have the problem of "it used
to mean X, but now it means Y". The
I guess I'm not quite sure why Crave is trying to find the merge base...
The PR is actually a branch in git - it has the full state of the repo that
should be tested. This is accomplished basically by the following [1]
git fetch origin pull/ID/head:BRANCH_NAME
git checkout BRANCH_NAME
So in the
