I think we should.

It (newtrunk) was created to test Hoss's side-by-sdie proposal, and
that approach looks to be working very well.

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.

Mike

On Mon, Mar 22, 2010 at 6:32 AM, Uwe Schindler <[email protected]> wrote:
> Are we now only working on newtrunk?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [email protected]
>
>> -----Original Message-----
>> From: Michael McCandless (JIRA) [mailto:[email protected]]
>> Sent: Monday, March 22, 2010 11:22 AM
>> To: [email protected]
>> Subject: [jira] Resolved: (LUCENE-2297) IndexWriter should let you
>> optionally enable reader pooling
>>
>>
>>      [ https://issues.apache.org/jira/browse/LUCENE-
>> 2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Michael McCandless resolved LUCENE-2297.
>> ----------------------------------------
>>
>>     Resolution: Fixed
>>
>> Fixed on newtrunk.
>>
>> > IndexWriter should let you optionally enable reader pooling
>> > -----------------------------------------------------------
>> >
>> >                 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
>> >
>> >         Attachments: LUCENE-2297.patch
>> >
>> >
>> > 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.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to