Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> Re: Upcoming merge of snapshots branch into trunk. (HBASE-6055 and HABSE-7290)


+
Jonathan Hsieh 2013-01-11, 13:33
+
Andrew Purtell 2013-01-11, 16:16
+
Jonathan Hsieh 2013-01-07, 18:07
Copy link to this message
-
Re: Upcoming merge of snapshots branch into trunk. (HBASE-6055 and HABSE-7290)
On Mon, Jan 7, 2013 at 10:07 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> Matteo, Jesse and I seem to be getting to the point where have core
> functionality for offline snapshots (disable table, snapshot) and online
> snapshot (snapshot an enabled table) committed, did another rev solidifying
> file layout, and have been steadily knocking off blocking and non-blocking
> follow-on subtasks.
>
>
Hurray!

> 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

> 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?)

> 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)).

> 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
+
Ted Yu 2013-01-07, 18:38
+
Jonathan Hsieh 2013-01-07, 18:58
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB