river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Code review release 2.2.1 - dedicated to Fred Oliver
Date Sat, 11 Feb 2012 12:18:55 GMT
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
View raw message