lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: New LuSolr trunk (was: RE: (LUCENE-2297) IndexWriter should let you optionally enable reader pooling)
Date Tue, 23 Mar 2010 13:15:20 GMT

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

> Hi all,
> 
> the discussion where to do the development after the merge, now gets actual:
> 
> 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.
> 
> I propose to do the following:
> 
> - 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.
> - Move the branch from https://svn.apache.org/repos/asf/lucene/solr/branches/newtrunk
to this new directory as "trunk"

OK, makes sense.  Frankly, I think we could just keep the name "java" for "lusolr", but "search"
would work too or even something as simple as dev.

> - 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).

Makes sense.  We can always move things again if we need to.  This isn't CVS after all.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message