hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Upcoming merge of snapshots branch into trunk. (HBASE-6055 and HABSE-7290)
Date Thu, 10 Jan 2013 18:46:13 GMT
It turns out that both Cloudera and Hortonworks have plans to backport this to 0.94 in their
respective distributions (I don't think that is a secret, apologies if it was).
This makes it a defacto standard, and would probably point towards porting this to the public
0.94 as well.

Maybe we can wait for both HW and Cloudera to finish the backport and stabilize and test it
and then port it to the "official" Apache distribution.


Thoughts?


-- Lars



________________________________
 From: Jonathan Hsieh <jon@cloudera.com>
To: dev@hbase.apache.org 
Sent: Wednesday, January 9, 2013 11:38 AM
Subject: Re: Upcoming merge of snapshots branch into trunk. (HBASE-6055 and HABSE-7290)
 
On Mon, Jan 7, 2013 at 11:44 PM, Stack <stack@duboce.net> wrote:
> On Mon, Jan 7, 2013 at 10:07 AM, Jonathan Hsieh <jon@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
// jon@cloudera.com
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message