hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: [VOTE] Merge branch HBASE-10070 to trunk
Date Sat, 07 Jun 2014 14:41:33 GMT
On Fri, Jun 6, 2014 at 5:05 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> My preference would be to do the rebase-then-merge style (last style in
> your comment). For each patch, I am hoping for all the changes between
> committed version and rebased version to be mechanical. I like having a
> linear history with explicit commit-to-patch mapping.
>
> If the changes are of a mechanical nature and that each patch compiles and
passes unit tests along the way, then rebase-then-merge is perfectly fine
by me.

Even though snapshots were fairly orthogonal to the rest of the codebase,
when we did merges we had problems maintaining the compiles and passes with
every commit invariants when we tried rebase-then-merge approach.  After
each rebase we would end up doing a bunch of work and still end up failing
unit tests.   In that case we (jesse, matteo, myself) went to the merge
approach.   We actually merged into the snapshot branch a few times fixing
things due to changes in trunk that broke parts of the snapshots branch.
Here's a more accurate picture of what the commit history looked like in
git (we dev'ed in git and in end had to recommit this all in svn).

m  (essentially empty merge patch).
|\
t |  (trunk patch with no impact)
| s6* (patch to fix newly introduced problem)
|/|
t |
t*|   (trunk patch that broke snapshots again)
| s5* (branch bug fixes due to merge)
| s4* (mechanical fixups due to the merge)
|/|
t |
t |
t |
| s3
| s2
| s1
|/
t
t

This approach was captured in github and had the added benefit of
preserving exact history, and having known good points preserving the
compile/unit test invariants on trunk.  (unfortunately, some of this
history was lost when we ported the git history over to svn, but that isn't
a problem any more).    If you want to see the whole thing, look at my git
repo:

git remote add jmhsieh git@github.com:jmhsieh/hbase.git
git log --oneline --graph --color jmhsieh/hbase-7290


Can we do history-preserving merge with the first style? I can do the
> rebases and upload interdiff if that is big so that we can compare on a
> per-patch basis.
>
>
It is possible.





> Enis
>
>
> On Fri, Jun 6, 2014 at 4:36 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
>
> > When we merged snapshots branch in we did this:
> >
> > t = trunk commit
> > s = snapshot branch commit
> > m = merge point.
> >
> > During work:
> > t
> > t
> > t
> > |  s3
> > |  s2
> > |  s1
> > |/
> > t
> > t
> >
> > During after merge:
> > m  (essentially empty merge patch).
> > t \
> > t |
> > t |
> > | s4* (fixups due to the merge)
> > | s3
> > | s2
> > | s1
> > |/
> > t
> > t
> >
> > Does your proposal mean you are going to do this instead?
> >
> > s3* (modified due to rebase)
> > s2* (modified due to rebase)
> > s1
> > t
> > t
> > t
> > | s (now dead hbase-10070 branch)
> > | s
> > | s
> > | s
> > |/
> > t
> > t
> >
> > If it is the then we should probably have a review of the modified
> patches.
> >  If it the same as the snapshot merge, then we just need a review of the
> > merge point delta (as well as a full review).
> >
> > Personally I prefer the merge for these large feature branches -- it
> > guarantees that each commit is compilable, and reflects what you guys
> have
> > been testing for a while.  If you go with the last approach you might
> have
> > stuff broken, and in the mainline commit path.
> >
> > Jon.
> >
> >
> >
> > On Tue, Jun 3, 2014 at 11:16 AM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> > >  ​
> > > On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <enis@apache.org> wrote:
> > >
> > > > This VOTE is for merging back the remaining changes in branch to
> trunk.
> > > If
> > > > passes, we will rebase the branch on top of current trunk, in which
> we
> > > will
> > > > keep the commit-per-issue log history. After that we will do a git
> > merge
> > > > for the branch keeping the history clean and not squashing the
> > commits. I
> > > > expect rebasing to be straightforward, however with some manual
> > conflict
> > > > resolution. After the merge we'll keep running the tests to make sure
> > > > everything is ok.
> > > >
> > >
> > > ​Just to clarify that would look something like this:
> > >
> > >      $ git checkout HBASE-10070
> > >      $ git rebase --ignore-date master
> > >      (fixups, git add, git rebase --continue, etc, etc, etc)
> > >      $ git checkout master
> > >      $ git merge HBASE-10070
> > >
> > > ?
> > >
> > > That sounds good to me, the final merge should be a fast forward merge.
> > >
> > > Use of ' --ignore-date' could be mildly controversial. It's not
> strictly
> > > necessary because the commits for 10070 will appear grouped in history,
> > but
> > > then dates on commits will be discontiguous in that section of
> history. I
> > > suggest using that option so the order of commits and dates sort the
> same
> > > on master.
> > >
> > >
> > > On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <enis@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Last week we started some discussion[4] for merging branch
> > hbase-10070[1]
> > > > into trunk. It seems like the consensus there is to do the merge
> sooner
> > > > rather than later.
> > > >
> > > >
> > > > We had branched hbase-10070 in Feb out of trunk[5]. The branch
> contains
> > > 55
> > > > jiras committed[2]. Out of these 55, 15 has already been committed to
> > > trunk
> > > > and backported to hbase-10070 branch[3].
> > > >
> > > > This VOTE is for merging back the remaining changes in branch to
> trunk.
> > > If
> > > > passes, we will rebase the branch on top of current trunk, in which
> we
> > > will
> > > > keep the commit-per-issue log history. After that we will do a git
> > merge
> > > > for the branch keeping the history clean and not squashing the
> > commits. I
> > > > expect rebasing to be straightforward, however with some manual
> > conflict
> > > > resolution. After the merge we'll keep running the tests to make sure
> > > > everything is ok.
> > > >
> > > > An overview of the changes, and the status of the work can be found
> > under
> > > > [4], [6] and [7].In summary, with the code in branch, you can create
> > > tables
> > > > with region replicas, do gets / multi gets and scans using TIMELINE
> > > > consistency with high availability. Region replicas periodically scan
> > the
> > > > files of the primary and pick up flushed / committed files. The RPC
> > > paths /
> > > > assignment, balancing etc are pretty stable. However some more
> > > performance
> > > > analysis and tuning is needed. Phase 2 work is being worked on under
> > > > HBASE-11183, and we have some working prototype for async-replicating
> > and
> > > > region splits. However, we believe even without those features, this
> > work
> > > > is useable (especially for read-only/bulk load tables) , and can be
> > > > released as an experimental feature in 1.0.
> > > >
> > > > Please indicate your choice:
> > > >
> > > > [ ] +1 on yes, merge branch hbase-10070 to trunk.
> > > > [ ] 0 on don't care
> > > > [ ] -1 don't merge, because ...
> > > >
> > > > I'll keep the vote running for 7 days, and close it Mon 9th of June,
> > PDT.
> > > >
> > > > Here is my official +1.
> > > >
> > > > Thanks,
> > > > Enis
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=log;h=refs/heads/hbase-10070
> > > > [2]
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/HBASE-11214?jql=fixVersion%20%3D%20hbase-10070%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolved
> > > > [3]
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/HBASE-10792?jql=fixVersion%20%3D%20hbase-10070%20and%20fixversion%20%3D%200.99.0%20AND%20project%20%3D%20HBASE%20AND%20status%20%3D%20resolved
> > > > [4] https://www.mail-archive.com/dev@hbase.apache.org/msg25795.html
> > > > [5]
> > > >
> > > >
> > >
> >
> https://github.com/apache/hbase/commit/e22c7efeac02efde3451a0c9ff9bdcd2725576d0
> > > > [6]
> > > >
> > > >
> > >
> >
> http://www.slideshare.net/enissoz/hbase-high-availability-for-reads-with-time
> > > > [7] https://issues.apache.org/jira/browse/HBASE-10070
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // jon@cloudera.com // @jmhsieh
> >
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message