curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: CURATOR-217?
Date Tue, 25 Aug 2015 23:15:32 GMT
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 <mckenzie.cam@gmail.com>
wrote:

> Thanks Scott,
> I will merge into master.
> cheers
>
> On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dragonsinth@gmail.com> 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 <
>> mckenzie.cam@gmail.com>
>> 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 <dragonsinth@gmail.com>
>> 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" <mckenzie.cam@gmail.com>
>> > > 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 <madrob@cloudera.com>
>> > 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 <
>> > > > mckenzie.cam@gmail.com>
>> > > > > 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 <
>> > > > > mckenzie.cam@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Thanks Mike,
>> > > > > > > Will give it a spin today some time.
>> > > > > > > cheers
>> > > > > > >
>> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
>> madrob@cloudera.com>
>> > > > > 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
<
>> > > > > > mckenzie.cam@gmail.com
>> > > > > > >> >
>> > > > > > >> 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
<
>> > > > dragonsinth@apache.org
>> > > > > >
>> > > > > > >> > 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 <
>> > > > > > >> > > jordan@jordanzimmerman.com> 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 (
>> > > > > > >> dragonsinth@apache.org)
>> > > > > > >> > >> 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 <
>> > > > > > >> > >> jordan@jordanzimmerman.com> 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 (
>> > > > > > >> dragonsinth@apache.org
>> > > > > > >> > )
>> > > > > > >> > >> > 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 <
>> > > > > > >> dragonsinth@apache.org>
>> > > > > > >> > >> > wrote:
>> > > > > > >> > >> >
>> > > > > > >> > >> > > Yeah, 217 & 161 were
the first two big things in
>> 3.0.
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > On Mon, Aug 24, 2015 at
9:53 AM, Jordan Zimmerman <
>> > > > > > >> > >> > > jordan@jordanzimmerman.com>
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 (
>> > > > > > >> > >> > >> mckenzie.cam@gmail.com)
wrote:
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> Yes, I merged it in
last week some time.
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> On Mon, Aug 24, 2015
at 3:25 PM, Jordan Zimmerman <
>> > > > > > >> > >> > >> jordan@jordanzimmerman.com>
wrote:
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> > Scott, did CURATOR-217
get merged into the new
>> > > > > CURATOR-3.0?
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> > -Jordan
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >
>> > > > > > >> > >> > >
>> > > > > > >> > >> >
>> > > > > > >> > >> >
>> > > > > > >> > >>
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

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