Return-Path: 
 <solr-dev-return-25038-apmail-lucene-solr-dev-archive=lucene.apache.org@lucene.apache.org>
Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org
Received: (qmail 19063 invoked from network); 23 Mar 2010 13:40:24 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 23 Mar 2010 13:40:24 -0000
Received: (qmail 81352 invoked by uid 500); 23 Mar 2010 13:40:21 -0000
Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org
Received: (qmail 81222 invoked by uid 500); 23 Mar 2010 13:40:21 -0000
Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:solr-dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:solr-dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:solr-dev@lucene.apache.org>
List-Id: <solr-dev.lucene.apache.org>
Reply-To: solr-dev@lucene.apache.org
Delivered-To: mailing list solr-dev@lucene.apache.org
Received: (qmail 81195 invoked by uid 99); 23 Mar 2010 13:40:20 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Mar 2010 13:40:20 +0000
X-ASF-Spam-Status: No, hits=-0.9 required=10.0
	tests=AWL,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gsiasf@gmail.com designates
 209.85.210.199 as permitted sender)
Received: from [209.85.210.199] (HELO mail-yx0-f199.google.com)
 (209.85.210.199)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Mar 2010 13:40:14 +0000
Received: by yxe37 with SMTP id 37so2018488yxe.21
        for <multiple recipients>; Tue, 23 Mar 2010 06:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:sender:subject:mime-version
         :content-type:from:in-reply-to:date:cc:content-transfer-encoding
         :message-id:references:to:x-mailer;
        bh=x0afsKD1XlrN3ozkvOJphrWfuX/87cUSrf927SgesTg=;
        b=A8HBO2LMBmoJilhdqu85ckIp9xczKhtzaMlFDMtAQMNppsSth9l6QtB+rlI8HkKzjW
         iryiHm5cIXsW8zG3yZh/jXccf38TEvpwyFkAjY6fuT0SIKUWdHDvfPaz0A/OAnl+oeTE
         Pn2wjw8PRbPdW3z66JmRS4Rh6pVb4c5JVhqg8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=R5E0B6CxwImVKgfbrX/J38hZ1++jkGYZ+9MspvlRCpips0MXkpr8GDe1mt9fnlY1Uy
         0MsgUnxTEy7w9c8UJSi7ygStL1tTXzb3osOswlfX8c/VHqLHKWDIfR0cIMrWwM6THa7N
         CP5iaMb+AYw9UTygozSieytMAkZqBNLEVO/KA=
Received: by 10.101.26.11 with SMTP id d11mr1982405anj.216.1269351592737;
        Tue, 23 Mar 2010 06:39:52 -0700 (PDT)
Received: from [10.0.0.77] (adsl-065-013-152-164.sip.rdu.bellsouth.net
 [65.13.152.164])
        by mx.google.com with ESMTPS id 16sm3726320gxk.5.2010.03.23.06.39.51
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 23 Mar 2010 06:39:52 -0700 (PDT)
Sender: Grant Ingersoll <gsiasf@gmail.com>
Subject: Re: New LuSolr trunk (was: RE: (LUCENE-2297) IndexWriter should let
 you optionally enable reader 	pooling)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Grant Ingersoll <gsingers@apache.org>
In-Reply-To: <000d01cac9bb$15dfdb60$419f9220$@de>
Date: Tue, 23 Mar 2010 09:39:50 -0400
Cc: <solr-dev@lucene.apache.org>,
  <general@lucene.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <326620FF-0EF3-4B17-89D6-D1873B927C40@apache.org>
References: <762061725.99641267802907331.JavaMail.jira@brutus.apache.org>
	 <000001cac9ab$0a48e360$1edaaa20$mkm@de>
 <9ac0c6aa1003220337m523981f3m801a78f4ab095f23@mail.gmail.com>
 <000d01cac9bb$15dfdb60$419f9220$@de>
To: java-dev@lucene.apache.org
X-Mailer: Apple Mail (2.1077)


On Mar 22, 2010, at 8:27 AM, Uwe Schindler wrote:

> Hi all,
>=20
> the discussion where to do the development after the merge, now gets =
actual:
>=20
> Currently a lusolr test-trunk is done as a branch inside solr =
(https://svn.apache.org/repos/asf/lucene/solr/branches/newtrunk). The =
question is, where to put the main development and how to switch, so =
non-developers that have checkouts of solr and/or lucene will see the =
change and do not send us outdated patches.
>=20
> I propose to do the following:
>=20
> - Start a new top-level project folder inside /lucene root svn folder: =
https://svn.apache.org/repos/asf/lucene/lusolr (please see "lusolr" as a =
placeholder name) and add branches, tags subfolders to it. Do not create =
trunk and do this together with the next step.

OK, I created https://svn.apache.org/repos/asf/lucene/dev/ and given =
appropriate rights.  Uwe, you can now do the rest of the move.  Once =
you've done it, let me know and I can make sure to add back the contrib =
rights.

> - Move the branch from =
https://svn.apache.org/repos/asf/lucene/solr/branches/newtrunk to this =
new directory as "trunk"
> - For lucene flexible indexing, create a corresponding flex branch =
there and svn copy it from current new trunk. Merge the lucene flex =
changes into it. Alternatively, land flex now. Or simply do svn copy of =
current flex branch instead of merging (may be less work).
> - Do the same for possible solr branches in development
> - Create a tag in the lucene tags folder and in the solr tags folder =
with the current state of each trunk. After that delete all contents =
from old trunk in solr and lucene and place a readme file pointing =
developers to the new merged trunk folder (for both old trunks). This =
last step is important, else people who checkout the old trunk will soon =
see a very outdated view and may send us outdated patches in JIRA. When =
the contents of old-trunk disappear it's obvious to them what happened. =
If they had already some changes in their checkout, the svn client will =
keep the changed files as unversioned (after upgrade). The history keeps =
available, so it's also possible to checkout an older version from trunk =
using @rev or -r rev. I did a similar step with some backwards =
compatibility changes in lucene (add a README).
>=20
> Uwe
>=20
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>=20
>=20
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Monday, March 22, 2010 11:37 AM
>> To: java-dev@lucene.apache.org
>> Subject: Re: (LUCENE-2297) IndexWriter should let you optionally =
enable
>> reader pooling
>>=20
>> I think we should.
>>=20
>> It (newtrunk) was created to test Hoss's side-by-sdie proposal, and
>> that approach looks to be working very well.
>>=20
>> Up until now we've been committing to the old trunk and then
>> systematically merging over to newtrunk.  I think we should now flip
>> that, ie, commit to newtrunk and only merge back to the old trunk if
>> for some strange reason it's needed.
>>=20
>> Mike
>>=20
>> On Mon, Mar 22, 2010 at 6:32 AM, Uwe Schindler <uwe@thetaphi.de> =
wrote:
>>> Are we now only working on newtrunk?
>>>=20
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>=20
>>>> -----Original Message-----
>>>> From: Michael McCandless (JIRA) [mailto:jira@apache.org]
>>>> Sent: Monday, March 22, 2010 11:22 AM
>>>> To: java-dev@lucene.apache.org
>>>> Subject: [jira] Resolved: (LUCENE-2297) IndexWriter should let you
>>>> optionally enable reader pooling
>>>>=20
>>>>=20
>>>>     [ https://issues.apache.org/jira/browse/LUCENE-
>>>> 2297?page=3Dcom.atlassian.jira.plugin.system.issuetabpanels:all-
>> tabpanel
>>>> ]
>>>>=20
>>>> Michael McCandless resolved LUCENE-2297.
>>>> ----------------------------------------
>>>>=20
>>>>    Resolution: Fixed
>>>>=20
>>>> Fixed on newtrunk.
>>>>=20
>>>>> IndexWriter should let you optionally enable reader pooling
>>>>> -----------------------------------------------------------
>>>>>=20
>>>>>                Key: LUCENE-2297
>>>>>                URL: https://issues.apache.org/jira/browse/LUCENE-
>>>> 2297
>>>>>            Project: Lucene - Java
>>>>>         Issue Type: Improvement
>>>>>           Reporter: Michael McCandless
>>>>>           Priority: Minor
>>>>>            Fix For: 3.1
>>>>>=20
>>>>>        Attachments: LUCENE-2297.patch
>>>>>=20
>>>>>=20
>>>>> For apps using a large index and frequently need to commit and
>>>> resolve deletes, the cost of opening the SegmentReaders on demand
>> for
>>>> every commit can be prohibitive.
>>>>> We an already pool readers (NRT does so), but, we only turn it on
>> if
>>>> NRT readers are in use.
>>>>> We should allow separate control.
>>>>> We should do this after LUCENE-2294.
>>>>=20
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>=20
>>>>=20
>>>> =
--------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>=20
>>>=20
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>=20
>>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>=20

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem using Solr/Lucene: =
http://www.lucidimagination.com/search