This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
see 130235 - Maros requested I file issue for local history for that situation.
there is no merge dialog in the local history
local history and the refactor preview diff view does not show the multibyte ok for one of the 2 diff windows of each ? Is that covered by this fix ? using utf-8 or mac-roman(an euc-jp) encoding - local history - current view mbyte is ok; previous one is not refactor preview - current view is ok; to be refactored window is not attached is gif.
Created attachment 58607 [details] image
to clarify - 1. what led to this being filed was what is seen on mac, which is attached 2. but in conversation with Maros, it was suggested to file issue also on localhistory related to the fix he did in 130235. ===> this might really be 2 separate things that are needed, the fix for 2. being done, but #1 might need a separate issue;; let me know. ken.frank@sun.com
looking at 130235 it seems like the issue is about the merge tool which isn't used by local history at all. however, what you have reported in your last post seems to be something else. i'll see if i can reproduce it...
i'm sorry but i'm unable to reproduce.
This problem does not occur on mac 10.5 with mercurial 1.0 or mercurial 0.9.5. It does occur with mac 10.4 with mercurial 0.9.5 (there is not currently mercurial 1.0 for mac 10.4)
Last comment from Padraig was meant to be for issue 130245, please ignore.
am leaving as incomplete for now as am not able to reproduce now on 10.4 or 10.5 but need more time to experiment with this - am assuming if its incomplete that it does not need to be waived for 6.1 ? if that is not true please put at p3. ken.frank@sun.com
hi, any update on this?
130235 was reopened but if there is no relation to functionality of that and for local history then I guess it can be closed -- but could you ask Maros about it first since he had mentioned that similar fix for 130235 might be needed for this funcitonality - and my interpretation of this might be - perhaps not as to the functionality itself, but the i18n or encoding handling approach underneath it that might be common ? ken.frank@sun.com
as already mentioned in my previous post - there is no relation between this one and 130235. closing this until as we have no solid evidence at his point