MakeHgPluginRemoteFSAware

(Difference between revisions)
(VCS Team)
(Next Steps)
Line 66: Line 66:
==Next Steps==
==Next Steps==
-
Join forces  
+
Join forces in ...
-
 
+
# create branch
-
====VCS Team====
+
# switch the SPI and do a simple implementation for one FS event - VCS Team
-
* switch the SPI and do a simple implementation for one FS event - from FSInterceptor, through to the appropriate hg command execution
+
# command execution - CND Team
-
* deal with specifics described in Other APIs
+
# file type change - CND Team
-
 
+
# Other APIs - VCS Team
-
====CND Team===
+
# Other issues - CND Team backed by VCS Team if necessary
-
will take over after the SPI switch and deal with:
+
-
* command execution
+
-
* file type change
+
-
*
+

Revision as of 11:52, 17 May 2012

Contents

The NetBeans Mercurial plugin should work with remote Filesytems

Problem description

Now, after issue 195124 was fixed, the time has approached to rewrite the NetBeans Mercurial plugin to work also with Remote Filesystems as well.

Goals

  • become fully remote filesytem capable
  • no significant changes/regression for cases when working only on a local filesystem:
    • functionality
    • performance
    • UI - note that most of our users still will be remote filesystem agnostic and shouldn't be unnecessarily exposed to any remote fs specifics - e.g. when setting up the hg client executable path.

Necessary actions

SPI

switch the Mercurial plugin to the SPI in o.n.m.versioning.core

effort <1dd

Command Execution

command execution has to work for local and remote filesystems

effort 1-3dd

Note that while this seems to be trivial thanks to extexecution, some minor issues will have to be resolved - e.g.:

  • in one running NetBeans instance there has to be setup (e.g. executable path) and depending on local/remote context properly invoked a hg client executable for two different environments.

File type

replace io.File with o.n.m.versioning.api.VCSFileProxy wherever necessary

effort 3-5dd

Note that:

  • the codebase is big (> 230 files, > 60 000 lines), and io.File is used throughout the whole module
  • cases might be discovered where the current VCSFileProxy functionality isn't sufficient yet - e.g. .getInputStream()
  • error prone because of the huge amount of changes (even though most of them trivial)

Other APIs

deal with other io.File APIs the Mercurial plugin is depending on

  • VCS/Indexing bridge - mercurial honors a contract between versioning modules and indexing, which ensures that long lasting vcs disk io operations do not interfere with indexing. It's io.File based and might become an issue. effort 1-3 dd
  • Friend API in Versioning Utils - make sure it does not break other VCSs (Git, Subversion) - e.g. commit dlg and search history API. effort 1-3dd
  • Integration with bugtracking - based on io.File - e.g. issue hyperlinks and commit hooks. effort 1-3dd

Other issues

deal with other specific problems caused by the plugin being written only for local usage - e.g.:

  • at several places, the mercurial plugin behaves differently depending on the os platform (retrieved via Utilities.isWindows/isMac/isUnix). While the local os might be windows, the remote isn't. Has to be evaluated and handled properly for each case. Note that not always there will be an evident relation to a file which could be used to provide the information about the local or remote context - e.g. the options panel is populated by an os specific hg executable path.
  • the plugin honors the os-wide {$userdir}/hgrc file. Now there will be two instances (local, remote) of the config file. Has to be properly handled depending on remote or local usecase.
  • remote FS aware FileChoosers have to be used where necessary
  • background status refresh relies on recursive listener. Is this going to work with remote FS?
  • ... and more is to be expected

effort 5-12dd

NOTE that the final extend of overall effort is hard to estimate:

  • big codebase
  • some areas haven't been touched for years and aren't well known (because they just work)
  • many dependencies
  • hg specific implementation details

Performance

Not expecting any significant changes in case of local, but due to the mentioned big amount of necessary changes in the codebase at least a rudimentary check for a potential regression would be desirable.

Testing

  • Tests have to be rewritten, new tests will be necessary
  • Due to the mentioned big amount of changes some regression is to be expected and should be thoroughly tested
  • Stabilization might drain resources as well.

Next Steps

Join forces in ...

  1. create branch
  2. switch the SPI and do a simple implementation for one FS event - VCS Team
  3. command execution - CND Team
  4. file type change - CND Team
  5. Other APIs - VCS Team
  6. Other issues - CND Team backed by VCS Team if necessary
Not logged in. Log in, Register

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