(note we initially started in github since the two main drivers were not committers when this started)
I'm looking into creating an svn branch from the 12/19 (?) original branch point, committing each patch to svn in that branch , and then merging in the snapshot branch where we merged in the snapshot in git. if i finish before we take care of nit fixes (like find bugs, javadoc, spacing) we'll commit to svn branch for follow up and when we get all the +1s to merge we merge into svn trunk. On Tuesday, February 12, 2013, Ted Yu wrote: > Lars: > Can you clarify whether it is required to keep revision history for the > merge ? > > Thanks > > On Tue, Feb 12, 2013 at 3:42 PM, lars hofhansl > <[email protected]<javascript:;>> > wrote: > > > Are we keeping the revision history of the snapshot branch when we do the > > merge? > > Or are you planning to apply the mega patch to trunk? > > > > ----- Original Message ----- > > From: Jonathan Hsieh <[email protected] <javascript:;>> > > To: [email protected] <javascript:;> > > Cc: > > Sent: Tuesday, February 12, 2013 2:12 PM > > Subject: Snapshots branch trunk merging > > > > Hey all, > > > > We did a branch merge of the snapshot branch (hbase-6055 and > > hbase-7290 combined) with trunk on 2/1/13. This merge initially had > > several always broken tests but since then Ted, Matteo and myself > > fixed all the always-broken unit tests. I've merged again today > > 2/12/13 [1], and posted a patch on HBASE-7290 for the hadoopqa bot to > > run. > > > > There are primarily four of us who worked on this branch -- Jesse Y, > > Matteo, Ted Yu and myself, so if we each +1, technically we would have > > the 3 +1's required and could merge. I wanted to solicit +1's from > > the four who worked on it (all committers now) and also find out if > > anyone else has started reviewing the code or intends to in the next > > few days. It is a large patch (1.3MB) that I can post on review > > board, but it may be easier to understand by going to the different > > individual jiras (some of which have design docs). Generally we've > > been using a looser of review then commit for each of the subtasks. If > > I get clean test runs from the QA bot and +1's from the folks who > > worked on it or planned on reviewing it, I'd like merge sooner rather > > than later. > > > > On the unit testing front, I've personally gotten one error-free unit > > tests runs runs and one with a failure in hbase-examples: > > > > > org.apache.hadoop.hbase.coprocessor.example.TestBulkDeleteProtocol.testBulkDeleteFamily. > > > > On the system testing side, I've been testing the pre-merge version > > outlined by Aleks [2] and it had been fairly robust on a 5 node > > cluster with fault injection. I've also done some testing on a 20 > > node cluster (no fault injection) and a few runs on a 100 node cluster > > where the snapshoting feature has been robust. > > > > Thanks, > > Jon. > > > > [1] https://github.com/jmhsieh/hbase/tree/snapshot-merge-0212 > > [2] http://markmail.org/message/pdbkq654ipuxyt6a > > > > -- > > // Jonathan Hsieh (shay) > > // Software Engineer, Cloudera > > // [email protected] <javascript:;> > > > > > -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // [email protected]
