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 <u...@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: u...@thetaphi.de > > >> -----Original Message----- >> From: Michael McCandless [mailto:luc...@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-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
