hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Upcoming merge of snapshots branch into trunk. (HBASE-6055 and HABSE-7290)
Date Wed, 09 Jan 2013 19:38:33 GMT
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
View raw message