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.
Summary: | @VCS.Registration to allow VCS plugins to take over the responsibility for hiding metadata | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | Tomas Stupka <tstupka> |
Component: | Code | Assignee: | Tomas Stupka <tstupka> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anebuzelsky, cyhelsky, jglick |
Priority: | P1 | Keywords: | API_REVIEW_FAST, PLAN |
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Mac OS X | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 197789 | ||
Bug Blocks: | 195985 |
Description
Tomas Stupka
2011-03-04 12:01:38 UTC
jarda suggested the following: add mechanism to register vcs systems via annotation which would provide all necessary data to versioning manager so that it didn't had to "awake" the vcs system as long as not really necessary because of user action or file event. @VCSRegistration would provide: - vcs system display name - main menu label - metadata folder name - action/folder to acces global actions (e.g. checkout) registered via @ActionRegistration vcs visibility could then rely on the provided metadata folder name without delegating to all vcs systems would also solve/improve some other issues we have to deal with in VCS: - class loading even if system isn't used at all - unnecessary overhead while creating the vcs menu - ... patch will follow http://hg.netbeans.org/core-main/rev/148b26148960 - changes in versioning http://hg.netbeans.org/core-main/rev/3a2c660ab841 - changes in subversion actually, it is enough to track this as a fast review ... Y01 Minor: Looks like the subversion is using "Versioning/Subversion/Global" for references to actions. What will happen in future, when Subversion will need to provide and register something else than actions? I mean should not the path contain "Actions" somehow? Like "Versioning/Subversion/Actions/Global"? Y02 Don't forget to adjust apichange date. Y03 I see the getPriority(Integer) method. You make sure the versioning.xyz.priority property is documented in arch.xml. Probably private API. Y04 "temporary hack to fix issue #195985" is not very systematic. I'd hope usage of VersioningSystem.Registration would eliminate that. Y05 Firing changes (e.g. calling 3rd party code) under "synchronized(support)" is dangerous. Y06 Performance test: There should be a test in ide.kit that starts the IDE, browses through whole content of Team menu, asks for all JMenuItems and their enabled state and verifies that no class from Subversion module is loaded. > Y01 Minor: Looks like the subversion is using "Versioning/Subversion/Global" > for references to actions. What will happen in future, when Subversion will > need to provide and register something else than actions? I mean should not the > path contain "Actions" somehow? Like "Versioning/Subversion/Actions/Global"? ok. done. > Y03 I see the getPriority(Integer) method. You make sure the > versioning.xyz.priority property is documented in arch.xml. Probably private > API. removed - won't be a part of the api. not even private. > Y04 "temporary hack to fix issue #195985" is not very systematic. I'd hope > usage of VersioningSystem.Registration would eliminate that. it isn't and the plan is to get it rid of it in scope of this issue. the svn relevant part was already removed, other systems will follow > Y05 Firing changes (e.g. calling 3rd party code) under "synchronized(support)" > is dangerous. done > Y06 Performance test: There should be a test in ide.kit that starts the IDE, > browses through whole content of Team menu, asks for all JMenuItems and their > enabled state and verifies that no class from Subversion module is loaded. will follow. cc Peter Cyhelsky on cc, will take care of it http://hg.netbeans.org/core-main/rev/91a9faa75df1 - changes in versioning http://hg.netbeans.org/core-main/rev/97e37510433a - changes in subversion one more thing: the subversion metadata folder might be "_svn" instead of the usual ".svn" in case that the environmental variable $SVN_ASP_DOT_NET_HACK is set. A mechanism is needed for the VCS infrastructure to dynamically determine in runtime what folder name is to be used in such a case. see: core-main #d16bb394fd9e for the suggested solution core-main #0086b01fc266 for the implementation and test will integrate tomorrow in case no objection is raised ... merged VCS and Subversion - core-main #4b35188452f3 hg and git will follow changes in mercurial core-main #899fc733525b changes in git core-main #625c9fe1ac0d fixed, closing ... Integrated into 'main-golden', will be available in build *201105310954* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/148b26148960 User: Tomas Stupka <tstupka@netbeans.org> Log: issue #196290 - VCS plugins should take over the responsibility for hiding metadata (register a versionig system via annotation) Integrated into 'main-golden', will be available in build *201106010401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/148b26148960 User: Tomas Stupka <tstupka@netbeans.org> Log: issue #196290 - VCS plugins should take over the responsibility for hiding metadata (register a versionig system via annotation) Integrated into 'main-golden', will be available in build *201106021001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/148b26148960 User: Tomas Stupka <tstupka@netbeans.org> Log: issue #196290 - VCS plugins should take over the responsibility for hiding metadata (register a versionig system via annotation) |