lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: lucene and solr trunk
Date Wed, 17 Mar 2010 13:09:17 GMT
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_gospodnetic@yahoo.com> wrote:
> +1 for this structure and this set of steps.
>  Otis
>
>
>
>
> ----- Original Message ----
>> From: Chris Hostetter <hossman_lucene@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
>

Mime
View raw message