river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Code review release 2.2.1 - dedicated to Fred Oliver
Date Sun, 12 Feb 2012 13:53:51 GMT
I'm going to be a little busy, worked over 80 hours last week, doesn't look much better this
week, should have a brief interlude next week.  Will attempt a merge again then.  Hopefully
it'll go a little better next time.

Cheers,

Peter.

----- Original message -----
> Simon IJskes - QCG wrote:
> > On 11-02-12 12:08, Peter wrote:
> > >
> > > ----- Original message -----
> > > > On 11-02-12 06:56, Peter wrote:
> > > > > Lets dedicate this release to Fred Oliver, please dive in and
> > > > > review recent
> > > > > code changes and ask questions, make sure the javadoc makes sense. 
> > > > > Let's make
> > > > > it the best release we can.
> > > > >
> > > > > I plan to release on April 9, exactly one year after Fred's
> > > > > passing, giving us
> > > > > less than 2 months to prepare the release.
> > > > >
> > > > > Peter.
> > > >
> > > > Your merge did not go ok, you reverted changes, and merged files that
> > > > did not change, thereby (potentially) changing the historic path of
> > > > that
> > > > file. Are you going to repair this before release.
> > >
> > > I'm glad you were watching Sim, I wasn't even aware it went awry.
> > >
> > > Sounds like I need to back out the changes&  try again.
> >
> > There are a few methods of backing out, i would prefer branching the
> > last correct revision number in trunk, moving the trunk, and moving
> > this branch in place of the trunk. I can do this if you want.
>
> Thanks Mate, I'd appreciate that.
> >
> > > Got any advice?
> >
> > The next time you merge, and the branch you merge from is old compared
> > to the trunk, you could make patch file, or diff and manually accept
> > line changes in Netbeans for instance by using the visual diff, under
> > the menu option 'Diff to'.
> >
> > There are different approaches to checking in, but i have no problem
> > with a partial commit, followed by many other partial commits, that
> > allow you to check each step. Those partial commits do not have to
> > compile in my view, as long as the result of these multiple commits is
> > a stable build in the end. (others have a more 'only commit compilable
> > steps' approach, unworkable in my view).
> >
>
> Thanks, I agree, that sounds like the best approach when dealing with a
> lot of changes.  I can commit package by package, and inspect as I go.
>
> Regards,
>
> Peter.
>


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