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.
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. Enis On Fri, Jun 6, 2014 at 4:36 PM, Jonathan Hsieh <j...@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 <apurt...@apache.org> > wrote: > > > > > On Mon, Jun 2, 2014 at 2:24 PM, Enis Söztutar <e...@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 <e...@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 > // j...@cloudera.com // @jmhsieh >
