Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F365CAF.50403@zeus.net.au>
Date: Sat, 11 Feb 2012 22:18:55 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Code review release 2.2.1 - dedicated to Fred Oliver
References: <1328939796.10216.22.camel@Nokia-N900-51-1>
   <4F36471A.9060103@qcg.nl> <1328958537.10851.5.camel@Nokia-N900-51-1>
 <4F36578F.6050707@qcg.nl>
In-Reply-To: <4F36578F.6050707@qcg.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.