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:29:34 GMT
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 <madrob@cloudera.com> 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 <mckenzie.cam@gmail.com>
> 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 <
> 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