I have raised CURATOR-254 for this. On Wed, Aug 26, 2015 at 10:41 AM, Cameron McKenzie <[email protected]> wrote:
> I've had a bit of a look at it and the test seems very fragile. It already > has a bit of built in margin for error, but it relies on the consumers > being able to consume messages off the queue faster than they are produced. > If more than 20 messages end up on the queue at any time then test test > fails. > > Anyway, I will raise a JIRA and we can discuss there. > > On Wed, Aug 26, 2015 at 9:29 AM, Cameron McKenzie <[email protected]> > wrote: > >> Thanks Mike, >> On master. I'll have a bit of a look into it and let you know. I think >> that it's a race condition based on how the test is structured. >> cheers >> >> On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <[email protected]> wrote: >> >>> Is this on 3.0 or master? Can you create a JIRA with some log output? >>> >>> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie < >>> [email protected]> >>> wrote: >>> >>> > Is anyone seeing fairly consistent failure of the >>> > >>> > TestBoundedDistributedQueue.testMulti:184 >>> > >>> > test? When I run from inside eclipse in isolation it seems ok, but >>> running >>> > a 'mvn test' seems to fail on this test with some consistency. The >>> changes >>> > for CURATOR-167 certainly haven't caused this to happen. >>> > cheers >>> > >>> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie < >>> [email protected]> >>> > wrote: >>> > >>> > > Thanks Scott, >>> > > I will merge into master. >>> > > cheers >>> > > >>> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <[email protected]> >>> > wrote: >>> > > >>> > >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just >>> > >> fast-foward merge it into master now. >>> > >> >>> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie < >>> > >> [email protected]> >>> > >> wrote: >>> > >> >>> > >> > Thanks Scott, >>> > >> > Done, would you mind checking the origin/CURATOR-167 to make sure >>> > that I >>> > >> > haven't done anything wrong! I have done a git pull on a different >>> > >> machine >>> > >> > and it seems to be ok. >>> > >> > cheers >>> > >> > >>> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum < >>> [email protected]> >>> > >> wrote: >>> > >> > >>> > >> > > You just force push your branch. >>> > >> > > >>> > >> > > If it's your feature branch, and you know you have it in a good >>> > state >>> > >> > > locally, you can just force push the remote branch into the same >>> > >> state. >>> > >> > > >>> > >> > > You'd never want to do that to master, a release branch, or >>> someone >>> > >> > else's >>> > >> > > branch. >>> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" < >>> > [email protected]> >>> > >> > > wrote: >>> > >> > > >>> > >> > > > Thanks Mike, >>> > >> > > > That was a good description. The CURATOR-167 branch is >>> definitely >>> > >> there >>> > >> > > as >>> > >> > > > it's been a pull request for the last few months. So, I'll >>> await >>> > >> your >>> > >> > > > thoughts in the morning. Alternatively, I can just merge >>> master >>> > >> instead >>> > >> > > of >>> > >> > > > rebasing it. >>> > >> > > > >>> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob < >>> [email protected]> >>> > >> > wrote: >>> > >> > > > >>> > >> > > > > Yea, that's the big downside with rebasing, is that remotes >>> > don't >>> > >> > > exactly >>> > >> > > > > keep up with the history. I'm going to try to explain this >>> as >>> > best >>> > >> > as I >>> > >> > > > > can, but usually I point people towards this excellent "Git >>> for >>> > >> Ages >>> > >> > 4 >>> > >> > > > and >>> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he >>> > talks >>> > >> > about >>> > >> > > > > rebases at the very very end, around the 1:30 mark. >>> > >> > > > > >>> > >> > > > > Essentially, your current version of the branch does not >>> have >>> > the >>> > >> > > remote >>> > >> > > > > version of the as an ancestor. Which is correct, when you >>> did >>> > the >>> > >> > > rebase, >>> > >> > > > > you wrote a new commit lineage. >>> > >> > > > > >>> > >> > > > > I didn't realize that there was already a CURATOR-167 branch >>> > >> pushed >>> > >> > to >>> > >> > > > the >>> > >> > > > > repo when I gave you those steps. I'll have to look at >>> what's >>> > >> going >>> > >> > on >>> > >> > > > with >>> > >> > > > > a fresh set of eyes in the morning. >>> > >> > > > > >>> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie < >>> > >> > > > [email protected]> >>> > >> > > > > wrote: >>> > >> > > > > >>> > >> > > > > > I just tried this and obviously I'm doing something wrong. >>> > >> > > > > > >>> > >> > > > > > git checkout CURATOR-167 >>> > >> > > > > > git pull >>> > >> > > > > > git rebase -i origin/master >>> > >> > > > > > >>> > >> > > > > > #This gives me a dialog with one commit with pick >>> > >> > > > > > Save and exit >>> > >> > > > > > #This gives a merge conflict and leaves me in a detached >>> head >>> > >> state >>> > >> > > (I >>> > >> > > > > > presume this is ok). >>> > >> > > > > > Fix up the merge conflict >>> > >> > > > > > git rebase --continue >>> > >> > > > > > #This gives me a dialog to commit the changes >>> > >> > > > > > Save and exit >>> > >> > > > > > #Everything seems fine at this point. Builds ok, tests >>> run ok. >>> > >> > > > > > >>> > >> > > > > > git push >>> > >> > > > > > >>> > >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167 >>> > >> (non-fast-forward) >>> > >> > > > > > error: failed to push some refs to ' >>> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git' >>> > >> > > > > > hint: Updates were rejected because the tip of your >>> current >>> > >> branch >>> > >> > is >>> > >> > > > > > behind >>> > >> > > > > > hint: its remote counterpart. Integrate the remote changes >>> > (e.g. >>> > >> > > > > > hint: 'git pull ...') before pushing again. >>> > >> > > > > > hint: See the 'Note about fast-forwards' in 'git push >>> --help' >>> > >> for >>> > >> > > > > details. >>> > >> > > > > > >>> > >> > > > > > There have been no changes on the branch since I did the >>> pull >>> > >> > before >>> > >> > > > the >>> > >> > > > > > rebase. >>> > >> > > > > > >>> > >> > > > > > Any ideas? >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > >>> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie < >>> > >> > > > > [email protected]> >>> > >> > > > > > wrote: >>> > >> > > > > > >>> > >> > > > > > > Thanks Mike, >>> > >> > > > > > > Will give it a spin today some time. >>> > >> > > > > > > cheers >>> > >> > > > > > > >>> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob < >>> > >> [email protected]> >>> > >> > > > > wrote: >>> > >> > > > > > > >>> > >> > > > > > >> if you're going to tray that, here's what you want to >>> do >>> > >> > (assuming >>> > >> > > > > > command >>> > >> > > > > > >> line) >>> > >> > > > > > >> >>> > >> > > > > > >> git checkout CURATOR-167 # start with the branch that >>> you >>> > are >>> > >> > > > changing >>> > >> > > > > > >> git rebase -i master # rebase the current branch on >>> top of >>> > >> the >>> > >> > > given >>> > >> > > > > > >> branch >>> > >> > > > > > >> >>> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie < >>> > >> > > > > > [email protected] >>> > >> > > > > > >> > >>> > >> > > > > > >> wrote: >>> > >> > > > > > >> >>> > >> > > > > > >> > Scott, >>> > >> > > > > > >> > I've been using a similar approach to Jordan given >>> that's >>> > >> what >>> > >> > > I'm >>> > >> > > > > > used >>> > >> > > > > > >> to, >>> > >> > > > > > >> > but I'm happy to try your approach. I'm going to try >>> and >>> > >> fix >>> > >> > up >>> > >> > > > > > >> CURATOR-167 >>> > >> > > > > > >> > as it will no longer cleanly merge (it's been sitting >>> > >> there a >>> > >> > > > > while). >>> > >> > > > > > >> So, I >>> > >> > > > > > >> > should rebase master into the CURATOR-167 branch? >>> > >> > > > > > >> > cheers >>> > >> > > > > > >> > >>> > >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum < >>> > >> > > > [email protected] >>> > >> > > > > > >>> > >> > > > > > >> > wrote: >>> > >> > > > > > >> > >>> > >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely >>> > >> possible >>> > >> > > to >>> > >> > > > > mess >>> > >> > > > > > >> > > things up badly. If I'm doing something >>> particularly >>> > >> risky, >>> > >> > > > I'll >>> > >> > > > > > just >>> > >> > > > > > >> > "git >>> > >> > > > > > >> > > branch original" before I start, so as to leave a >>> > branch >>> > >> > > pointer >>> > >> > > > > at >>> > >> > > > > > my >>> > >> > > > > > >> > > start point as a safe recovery if it goes south. I >>> > also >>> > >> use >>> > >> > > > gitk >>> > >> > > > > to >>> > >> > > > > > >> > > visualize sometimes. >>> > >> > > > > > >> > > >>> > >> > > > > > >> > > Another major selling point for rebase (-i) is that >>> > it's >>> > >> > > > *really* >>> > >> > > > > > >> hard to >>> > >> > > > > > >> > > merge the wrong branch. If the list of commits >>> that >>> > >> comes >>> > >> > up >>> > >> > > > > > doesn't >>> > >> > > > > > >> > look >>> > >> > > > > > >> > > basically correct, you probably did something >>> wrong-- >>> > >> trying >>> > >> > > to >>> > >> > > > > > rebase >>> > >> > > > > > >> > onto >>> > >> > > > > > >> > > the wrong branch will give you tons of commits, >>> most of >>> > >> > which >>> > >> > > > > aren't >>> > >> > > > > > >> > yours. >>> > >> > > > > > >> > > >>> > >> > > > > > >> > > I think what you've been doing is fine, it's >>> definitely >>> > >> the >>> > >> > > > right >>> > >> > > > > > >> > approach >>> > >> > > > > > >> > > if you're doing a merge strategy! I've just ended >>> up >>> > >> > > > gravitating >>> > >> > > > > > to a >>> > >> > > > > > >> > > rebase strategy over the years for the reasons I've >>> > >> > mentioned. >>> > >> > > > > > >> > > >>> > >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman >>> < >>> > >> > > > > > >> > > [email protected]> wrote: >>> > >> > > > > > >> > > >>> > >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up >>> > several >>> > >> > > > projects >>> > >> > > > > > >> with >>> > >> > > > > > >> > it >>> > >> > > > > > >> > >> so I can’t even type the letters without breaking >>> > into a >>> > >> > > sweat. >>> > >> > > > > > "git >>> > >> > > > > > >> > rebase >>> > >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been >>> > doing >>> > >> - >>> > >> > let >>> > >> > > > me >>> > >> > > > > > >> know if >>> > >> > > > > > >> > >> it’s OK. For branches that are off of >>> CURATOR-3.0, I >>> > >> never >>> > >> > > > merge >>> > >> > > > > > >> > master. I >>> > >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. >>> In >>> > >> fact, >>> > >> > > > should >>> > >> > > > > we >>> > >> > > > > > >> > have a >>> > >> > > > > > >> > >> branch naming scheme to enforce this? >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> -Jordan >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum ( >>> > >> > > > > > >> [email protected]) >>> > >> > > > > > >> > >> wrote: >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature" >>> > branch I >>> > >> > just >>> > >> > > > > mean >>> > >> > > > > > >> the >>> > >> > > > > > >> > >> stable branch everyone is working against (3.0 or >>> > >> master) >>> > >> > > vs. a >>> > >> > > > > > >> feature >>> > >> > > > > > >> > >> branch where you're actively working. >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> You'll get to a point in development where you'll >>> > think >>> > >> > "Hey, >>> > >> > > > > there >>> > >> > > > > > >> are >>> > >> > > > > > >> > >> changes on the main branch I'm working against >>> that I >>> > >> > really >>> > >> > > > need >>> > >> > > > > > to >>> > >> > > > > > >> > pull >>> > >> > > > > > >> > >> into my feature branch." At that point >>> (particularly >>> > if >>> > >> you >>> > >> > > > have >>> > >> > > > > an >>> > >> > > > > > >> svn >>> > >> > > > > > >> > >> background) you'll be tempted to merge the main >>> branch >>> > >> into >>> > >> > > > your >>> > >> > > > > > >> feature >>> > >> > > > > > >> > >> branch. I would suggest not doing that, as it >>> makes >>> > the >>> > >> > > history >>> > >> > > > > > very >>> > >> > > > > > >> > muddy >>> > >> > > > > > >> > >> to follow. Instead, my workflow is usually more >>> like >>> > >> this: >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was >>> originally >>> > >> > > branched >>> > >> > > > > off >>> > >> > > > > > >> 3.0, >>> > >> > > > > > >> > >> and I want to pull in new changes. >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> git remote update >>> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0 >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> This pulls up an editor that gives me the list of >>> > >> commits >>> > >> > to >>> > >> > > > > > rebase. >>> > >> > > > > > >> I >>> > >> > > > > > >> > >> would typically exit out of the editor to at this >>> > point >>> > >> to >>> > >> > > > accept >>> > >> > > > > > the >>> > >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do >>> things >>> > like >>> > >> > > > reorder >>> > >> > > > > > the >>> > >> > > > > > >> > list, >>> > >> > > > > > >> > >> or squash commits like like "wip" or "minor >>> reformat" >>> > >> into >>> > >> > a >>> > >> > > > more >>> > >> > > > > > >> > curated >>> > >> > > > > > >> > >> set of logical commits. >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> Once you exit the editor, git goes through and >>> applies >>> > >> each >>> > >> > > > > commit, >>> > >> > > > > > >> one >>> > >> > > > > > >> > at >>> > >> > > > > > >> > >> a time, to the head of the target branch. It's >>> like >>> > >> picking >>> > >> > > up >>> > >> > > > > your >>> > >> > > > > > >> > commit >>> > >> > > > > > >> > >> chain and dumping it at the end of the target >>> branch, >>> > >> as if >>> > >> > > all >>> > >> > > > > > your >>> > >> > > > > > >> > work >>> > >> > > > > > >> > >> had been done against what's now the head of that >>> > >> branch. >>> > >> > > > You'll >>> > >> > > > > > may >>> > >> > > > > > >> > have >>> > >> > > > > > >> > >> to fix conflicts along the way, but usually not >>> much >>> > >> more >>> > >> > > than >>> > >> > > > if >>> > >> > > > > > you >>> > >> > > > > > >> > did >>> > >> > > > > > >> > >> it as a merge. >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> I'd encourage us to try this out a couple times >>> and >>> > get >>> > >> a >>> > >> > > feel >>> > >> > > > > for >>> > >> > > > > > >> the >>> > >> > > > > > >> > >> rebase flow. It's a little more to get your head >>> > around >>> > >> at >>> > >> > > > first, >>> > >> > > > > > but >>> > >> > > > > > >> > the >>> > >> > > > > > >> > >> upside is you end up with really easy to follow >>> commit >>> > >> > > > histories, >>> > >> > > > > > >> which >>> > >> > > > > > >> > >> makes it way easier to untangle problems later if >>> they >>> > >> crop >>> > >> > > up. >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan >>> Zimmerman < >>> > >> > > > > > >> > >> [email protected]> wrote: >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > >> > Can you explain this in detail? For me, I have >>> some >>> > >> > > features >>> > >> > > > > that >>> > >> > > > > > >> are >>> > >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a >>> kind of >>> > >> > > master. >>> > >> > > > > The >>> > >> > > > > > >> true >>> > >> > > > > > >> > >> > “master” is Curator 2.x only, right? >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > -Jordan >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum ( >>> > >> > > > > > >> [email protected] >>> > >> > > > > > >> > ) >>> > >> > > > > > >> > >> > wrote: >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > BTW: I noticed a couple of new commits >>> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8 >>> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) >>> where >>> > 3.0 >>> > >> is >>> > >> > > > > getting >>> > >> > > > > > >> > merged >>> > >> > > > > > >> > >> > into feature branches. Almost every project I've >>> > been >>> > >> on >>> > >> > we >>> > >> > > > > don't >>> > >> > > > > > >> tend >>> > >> > > > > > >> > >> to >>> > >> > > > > > >> > >> > do that as it leads to confusing history (this >>> isn't >>> > >> just >>> > >> > > > > > >> aesthetic, >>> > >> > > > > > >> > it >>> > >> > > > > > >> > >> > can >>> > >> > > > > > >> > >> > get harder for tooling to figure out what >>> happened). >>> > >> If I >>> > >> > > > want >>> > >> > > > > to >>> > >> > > > > > >> pull >>> > >> > > > > > >> > >> > changes from the main branch into my feature >>> > branch, I >>> > >> > > would >>> > >> > > > > > >> typically >>> > >> > > > > > >> > >> > *rebase* my feature branch against the main >>> branch. >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum < >>> > >> > > > > > >> [email protected]> >>> > >> > > > > > >> > >> > wrote: >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things >>> in >>> > >> 3.0. >>> > >> > > > > > >> > >> > > >>> > >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan >>> Zimmerman >>> > < >>> > >> > > > > > >> > >> > > [email protected]> wrote: >>> > >> > > > > > >> > >> > > >>> > >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The >>> issue is >>> > >> still >>> > >> > > > open >>> > >> > > > > in >>> > >> > > > > > >> > Jira. >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron >>> > >> McKenzie ( >>> > >> > > > > > >> > >> > >> [email protected]) wrote: >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> Yes, I merged it in last week some time. >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan >>> > Zimmerman < >>> > >> > > > > > >> > >> > >> [email protected]> wrote: >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the >>> new >>> > >> > > > > CURATOR-3.0? >>> > >> > > > > > >> > >> > >> > >>> > >> > > > > > >> > >> > >> > -Jordan >>> > >> > > > > > >> > >> > >> > >>> > >> > > > > > >> > >> > >> > >>> > >> > > > > > >> > >> > >> > >>> > >> > > > > > >> > >> > >> >>> > >> > > > > > >> > >> > > >>> > >> > > > > > >> > >> > > >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> > >>> > >> > > > > > >> > >> >>> > >> > > > > > >> > > >>> > >> > > > > > >> > > >>> > >> > > > > > >> > >>> > >> > > > > > >> >>> > >> > > > > > > >>> > >> > > > > > > >>> > >> > > > > > >>> > >> > > > > >>> > >> > > > >>> > >> > > >>> > >> > >>> > >> >>> > > >>> > > >>> > >>> >> >> >
