Hi, If we are developing on newtrunk and merging to the old trunk, what issues are preventing it from becoming 'the trunk'? or was that what you were suggesting?
Cheers Chris On Mon, Mar 22, 2010 at 11:37 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > 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 <u...@thetaphi.de> wrote: > > Are we now only working on newtrunk? > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > >> -----Original Message----- > >> From: Michael McCandless (JIRA) [mailto:j...@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 > >> > >> > >> [ 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: java-dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
