You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Uwe Schindler <uw...@thetaphi.de> on 2010/04/01 14:04:19 UTC

RE: Landing the flex branch

Hi,

we should think about how to merge the changes to trunk. I can try this out during the weekend, to merge back the changes to trunk, but this can be very hard. So we have the following options:

Try a merge back: This would let flex appear as a single commit to trunk, so the history of trunk would be preserved. If somebody wants to see the changes in the flex branch, he could ask for them (e.g. in TortoiseSVN there is a checkbox "Include merged revisions"). If this is not easy or fails, we can do the following:

- Create a big diff between current trunk and flex (after flex is merged up to trunk). Attach this patch to an issue and let everybody review. After that we can apply the patch to trunk. This would result in the same behavior for trunk, no changes lost, but all changes in flex cannot be reviewed.
- Delete current trunk and svn move the branch to trunk (after flex is merged up to trunk): This would make the history of flex the current history. The drawback: You losse latest trunk changes since the split of flex. Instead you will only see the merge messages. Therefore we should see this only as a last chance.

Comments?

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Tuesday, March 30, 2010 5:35 PM
> To: java-dev@lucene.apache.org
> Subject: Landing the flex branch
> 
> I think the time has finally come!  Pending one issue (LUCENE-2354 --
> Uwe), I think flex is ready to land.... I think the other issues with
> Fix
> Version = Flex Branch can be moved to 3.1 after we land.
> 
> We still use the pre-flex APIs in a number of places... I think this
> is actually good (so we continue to test the back-compat emulation
> layer).  With time we can cut them over.
> 
> After flex, there are a number of fun things to explore.  EG, we need
> to make attributes work well with codecs & indexing/searching (with
> Multi/DirReader, serailize/unserialize, etc.); we need a BytesRef +
> packed ints FieldCache StringIndex variant which should use much less
> RAM in certain cases; we should build a fast core PForDelta codec;
> more queries can cutover to operating directly on byte[] terms, etc.
> But these can all come with time...
> 
> Thoughts/issues/objections?
> 
> Mike
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Re: Landing the flex branch

Posted by Shai Erera <se...@gmail.com>.
bq. Try a merge back: This would let flex appear as a single commit to
trunk, so the history of trunk would be preserved.

 +1 for that - I think the history of trunk is important to preserve.
And there is also a way to ask for flex's history so everybody win?

Shai

On Thursday, April 1, 2010, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> we should think about how to merge the changes to trunk. I can try this out during the weekend, to merge back the changes to trunk, but this can be very hard. So we have the following options:
>
> Try a merge back: This would let flex appear as a single commit to trunk, so the history of trunk would be preserved. If somebody wants to see the changes in the flex branch, he could ask for them (e.g. in TortoiseSVN there is a checkbox "Include merged revisions"). If this is not easy or fails, we can do the following:
>
> - Create a big diff between current trunk and flex (after flex is merged up to trunk). Attach this patch to an issue and let everybody review. After that we can apply the patch to trunk. This would result in the same behavior for trunk, no changes lost, but all changes in flex cannot be reviewed.
> - Delete current trunk and svn move the branch to trunk (after flex is merged up to trunk): This would make the history of flex the current history. The drawback: You losse latest trunk changes since the split of flex. Instead you will only see the merge messages. Therefore we should see this only as a last chance.
>
> Comments?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Tuesday, March 30, 2010 5:35 PM
>> To: java-dev@lucene.apache.org
>> Subject: Landing the flex branch
>>
>> I think the time has finally come!  Pending one issue (LUCENE-2354 --
>> Uwe), I think flex is ready to land.... I think the other issues with
>> Fix
>> Version = Flex Branch can be moved to 3.1 after we land.
>>
>> We still use the pre-flex APIs in a number of places... I think this
>> is actually good (so we continue to test the back-compat emulation
>> layer).  With time we can cut them over.
>>
>> After flex, there are a number of fun things to explore.  EG, we need
>> to make attributes work well with codecs & indexing/searching (with
>> Multi/DirReader, serailize/unserialize, etc.); we need a BytesRef +
>> packed ints FieldCache StringIndex variant which should use much less
>> RAM in certain cases; we should build a fast core PForDelta codec;
>> more queries can cutover to operating directly on byte[] terms, etc.
>> But these can all come with time...
>>
>> Thoughts/issues/objections?
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org