Bug 196290 - @VCS.Registration to allow VCS plugins to take over the responsibility for hiding metadata
@VCS.Registration to allow VCS plugins to take over the responsibility for hi...
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Code
7.0
PC Mac OS X
: P1 (vote)
: 7.1
Assigned To: Tomas Stupka
issues@versioncontrol
: API_REVIEW_FAST, PLAN
Depends on: 197789
Blocks: 195985
  Show dependency treegraph
 
Reported: 2011-03-04 12:01 UTC by Tomas Stupka
Modified: 2011-06-02 21:04 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Stupka 2011-03-04 12:01:38 UTC
when hiding metedata vcs plugins rely on the system wide file ignore patterns in options > misc > file. This is unfortunate for several reasons and obviously each vcs system should take care for it's own metadata. for more info see also #195985

current state:
========
1.) there is 1 VcsVisibilityQueryImplementation registered in the lookup which
delegates to the relevant vcs system for a given file. This proces might take
some time due to eventual disk access in VCSManager as well as because of the
slow isVisible() execution in the particular vcs system. Therefore
vcsVQ.isVisible() returns an optimistic fake true (or a cached value if
available), asynchronously checks for the real value and fires visibility
changed if necessary. 

As for now the described mechanism works fine:
A) we typically have to deal only with a few deleted folders, so caching only a
few values etc. 
B) it doesn't really hurt to return true for a svn deleted folder and
reevaluate a moment later

From now on:
=========
ad A) we would have to deal with a lot more metadata (e.g .svn) folders. Might have some
impact in the IDE...
ab B) we always have to return false for metadata so the necessary evaluation can't
be made asynchronously as described in 1.)

2.) hiding svn metadata via svnVQ wouldn't work for cases of mixed vcs setups -
e.g. hgsvn (see also http://netbeans.org/bugzilla/show_bug.cgi?id=174305) as
the VcsVisibilityQueryImplementation would delegate only to the hgVQ.


suggested fix:
=========
add a new method to o.n.m.versioning.spi.VCSVisibilityQuery which would be synchronously
called in VcsVisibilityQueryImplementation for each vcs system.
Comment 1 Tomas Stupka 2011-04-15 13:53:40 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
Comment 2 Tomas Stupka 2011-04-29 16:57:03 UTC
http://hg.netbeans.org/core-main/rev/148b26148960 - changes in versioning
http://hg.netbeans.org/core-main/rev/3a2c660ab841 - changes in subversion
Comment 3 Tomas Stupka 2011-05-16 11:51:06 UTC
actually, it is enough to track this as a fast review ...
Comment 4 Jaroslav Tulach 2011-05-20 09:33:13 UTC
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.
Comment 5 Tomas Stupka 2011-05-20 14:58:17 UTC
> 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
Comment 6 Tomas Stupka 2011-05-25 14:59:21 UTC
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
Comment 7 Tomas Stupka 2011-05-26 10:29:16 UTC
will integrate tomorrow in case no objection is raised ...
Comment 8 Tomas Stupka 2011-05-30 13:32:36 UTC
merged VCS and Subversion - core-main #4b35188452f3

hg and git will follow
Comment 9 Tomas Stupka 2011-05-31 07:12:36 UTC
changes in mercurial core-main #899fc733525b
Comment 10 Tomas Stupka 2011-05-31 16:22:33 UTC
changes in git core-main #625c9fe1ac0d

fixed, closing ...
Comment 11 Quality Engineering 2011-05-31 19:21:16 UTC
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)
Comment 12 Quality Engineering 2011-06-01 13:24:51 UTC
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)
Comment 13 Quality Engineering 2011-06-02 21:04:44 UTC
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)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo