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.
