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.
