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. >
