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.
When I work on two computers (home & office) and set some options in one Netbeans I want on other Netbeans import (after export on first) settings from first. This export/import must have: 1. keymap 2. editor settings 3. plugins settings (which are active and which are disabled) 4. when plugins have config - this config (I work with C++ - compiler settins, path and others)
*** Issue 127810 has been marked as a duplicate of this issue. ***
*** Issue 72491 has been marked as a duplicate of this issue. ***
*** Issue 122690 has been marked as a duplicate of this issue. ***
*** Issue 134758 has been marked as a duplicate of this issue. ***
While disagreeing taht Issue 134758 is just a duplicate of this, I add the content of it here, hoping my comments will be considered, too: It's a pain to do quality testing with netbeans, because one cannot reuse settings from daily builds in a final version. When looking at the decreasing quality of NB 6.0 and 6.1 (never seen needed patches before), it seems, less people are willing to test NB. OTOH, I guess it wouldn't cause too many problems, to add the dev folder to the possible sources of settings reusage. And, to add an action to the Tools menu for reusing settings shouldn't be complicated, either. Probably, even a UI could be added for using only part of the settings? Of course, this would be more work ... Sth. like this would be great: - a Dropdown list with the available settings versions - a project selector, which projects should be upgraded (as there are sometimes chenges in project files structure) - a button group for module setting: either import all settings for all installed modules, or only fur new ones (i.e. You'll not get every module installed into NB at first time, there will be some modules to be installed later, e.g. when they become stable)
In general the imports are supported only FROM FINAL version to FINAL version by purpose. The userdirs for development version are not stable. And nobody assures that setting in one dev-userdir will be the same (or presented at all) in userdir of next dev build. ---------------------- @avp: 1,2, The set of settings that are imported is well defined in . All the settings listed in this table are copied from "old" userdir to "new" userdir during import of setting when the new IDE is started first time. But it is up to a module what it does with the imported settings. In the worst case it can ignore the settings. 3, http://www.netbeans.org/issues/show_bug.cgi?id=79310 4, It would be really difficult to import settings of a plugin. The IDE has no info about setting of particular plugin. ---------------------- @epdv >When looking at the decreasing quality of NB 6.0 and 6.1 (never seen needed patches before) :))))) There is nothing like bugless software outhere. IMO, the patches can help users to solve important issue immediatelly. It's a pity that you see it as decreasing of quality of NB. I see it as improving NB quality. By providing patches the NB team never said - hey, we give up on quality of the product. We will provide patches. - It is complete opposite.
what is imported for 6.1 http://wiki.netbeans.org/NB61SettingsMigrationTesting
@lhasik: Seems I've not explained my point clearly: The point is not: providing patches, but: the necessity of providing patches. I'm seeing this as a sign of too few users trying the dev builds, resulting in too few bug reports at dev time, so too much bugs remain for the final release - and have to be patched. About the stability of settings between dev builds (that's about Your answer to avp): I've rarely had issues about settings from one dev build to another - probably because I'm updating at least once a week - usually NB devs seem not to want to modify there settings again and again ... So, it should not cause problems to migrate the settings, at least from those dev builds installed after feature freeze. OTH, this issue here would probably give the chance to create a "hardened" settings api (well documented, of course, so it'll be used by every module developer ;-) ). It could probably be done this way: 3 months calling for usage scenarios and requirements, 2 months design, 1 month implementation, 3 months quality testing - it could be out then in spring 2009 ...
Import/Export settings was implemented in NB 6.8 I guess, so far it works as expected.