Git, Maven, Hg, etc., all sound great for the future, but let's focus now on the baby step (how to re-org svn), today, so we can land the Solr upgrade work now being done on a branch...
Hoss's side-by-side proposal sounds great... and his concrete steps "that could be done today" look good (I'm hoping Uwe "the policeman who wears many hats" volunteers ;). Mike On Wed, Mar 17, 2010 at 8:05 AM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > +1 for this structure and this set of steps. > Otis > > > > > ----- Original Message ---- >> From: Chris Hostetter <hossman_luc...@fucit.org> >> To: solr-dev@lucene.apache.org >> Sent: Tue, March 16, 2010 6:46:19 PM >> Subject: Re: lucene and solr trunk >> >> : Otis, yes, I think so, eventually. But that's gonna take much more >> discussion. > : > : I don't think this initial cutover should try to "solve" >> how modules > : will be organized, yet... we'll get there, >> eventually. > > But we should at least consider it, and not move in a >> direction that's > distinct from the ultimate goal of better refactoring >> (especailly since > that was one of the main goals of unifying development >> efforts) > > Here's my concrete suggestion that could be done today (for >> simplicity: > $svn = >> target=_blank >https://svn.apache.org/repos/asf/lucene)... > > svn >> mv $svn/java/trunk $svn/java/tmp-migration > svn mkdir >> $svn/java/trunk > svn mv $svn/solr/trunk $svn/java/trunk/solr > >> svn mv $svn/java/tmp-migration $svn/java/trunk/core > > At which >> point: > > 0. People who want to work only on "Lucene-Java" can start >> checking out > $svn/java/trunk/core (i'm pretty sure existing checkouts will >> continue to > work w/o any changes, the svn info should just update >> itself) > > 1. build files can be added to (the new) $svn/java/trunk to build >> ./core > followed by ./solr > > 2. the build files in $svn/java/trunk/solr >> can be modified to look at > ../core/ to find lucene jars > > 3. people who >> care about Solr (including all committers) should start > checking out and >> building all of $svn/java/trunk > > 4. Long term, we could choose to branch >> all of $svn/java/trunk > for releases ... AND/OR we could choose to branch >> specific modules > (ie: solr) independently (with modifications to the build >> files on those > branches to pull in their dependencies from alternate >> locations > > 5. Long term, we can start refactoring additional "modules" out >> of > $svn/java/trunk/solr and $svn/java/trunk/core (like >> > $svn/java/trunk/core/contrib) into their own directory in >> $svn/java/trunk > > 6. Long term, people who want to work on more then just >> "core" but don't > care about certain "modules" (like solr) can do a simple >> non-recursive > checkout of $svn/java/trunk and then do full checkouts of >> whatever modules > they care about > > > (Please note: I'm just trying to >> list things we *could* do if we go this > route, i'm not advocating that we >> *should* do any of these things) > > I can't think of any objections people >> have raised to any of the previous > suggestions which apply to this >> suggestion. Is there anything people can > think of that would be >> useful, but not possible, if we go this route? > > > -Hoss >
