On Mon, Jan 7, 2013 at 11:44 PM, Stack <st...@duboce.net> wrote: > On Mon, Jan 7, 2013 at 10:07 AM, Jonathan Hsieh <j...@cloudera.com> wrote: >> Aside from asking for reviews, there are a few outstanding questions we'd >> love to get your feedback on: >> HBASE-7471 - default configuration so that snapshots are available by >> default? >> > > > +1 on enabling by default in trunk/0.96 >
Ok, unless we hear other wise, we'll move forward on that. > > >> HBASE-7360 - do we backport offline snapshots to the apache hbase 0.94 >> line? >> >> > +0 tending toward -1. Patch is large for little benefit: i.e. offline > merge (you have to take table offline, right?) > Lars H hinted at this so I'll close that issues as won't do. > > >> So where is the code and jiras? Currently, there are two branches -- an >> offline snapshot only branch (HBASE-6055) here ( >> https://github.com/jyates/hbase/tree/snapshots aka >> https://github.com/jmhsieh/hbase/tree/hbase-6055) and an offline + online >> one (HBASE-7290) here >> (https://github.com/jmhsieh/hbase/tree/snapshots). Currently the >> difference between the two are 3-4 patches (they are fairly substantial but >> primarily additive). We were being conservative initially and had hoped >> that we could of done an offline merge earlier (and possibly merge with 94) >> and then a second round when the online snapshot was more robust. If our >> testing goes well this week, for trunk I'd lean more towards just doing one >> merge pass with the offline+online branch. >> >> > So, you want us review over in the branches? Or do you have updated > patches attached to 6055 and 7290? (Or you want us to wait till there is > the later reference mega-patch posted up on rb -- if rb will take it > (smile)). > > I'll post the mega patch when I have a version merged with trunk. Currently I've done a version but it fails on several unit tests. The individual patches are a good breakdown of the different modules that contribute to the snapshot feature -- for now it would probably make the most sense to get familiar with that before diving in to all the code. > >> 1) just commit the consolidated mega patch to trunk. (every trunk step >> should compile, but we lose blame information) >> 2) rebase each patch and then a fix up patch at the end (yuck -- may have >> broken intermediate steps, but keeps blame info) >> 3) create a branch in svn (we've been in github) and, after we do an svn >> merge of the snapshot branch into trunk. (more work, but each commit in >> each branch should compile, keep blame information). >> >> > For #3, when you create a branch, it would be made with what is out on > github after github had been brought current w/ trunk? Then, you would > merge in the svn branch into trunk? Isn't the commit history only going to > be one level deep? i.e. 'branch made from what was in github?" Or will it > have more than this? > > St.Ack I was hoping to bring each of the individual github commits as svn branch commits and then use the svn merge to form the top of #3. I need to spend some time experimenting with svn to do this. Another suggestion in the long run is to move hbase to an apache git repo completely -- apparently several of the newer projects like bigtop and whirr have moved to git completely. Jon -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // j...@cloudera.com
