MakeHgPluginRemoteFSAware

(Difference between revisions)
m (File type)
m (Other APIs)
Line 30: Line 30:
===Other APIs===
===Other APIs===
deal with other io.File APIs the Mercurial plugin is depending on
deal with other io.File APIs the Mercurial plugin is depending on
 +
* VCS/Indexing bridge - in case scanning/indexing deals with remote sources
'''effort''' currently not aware of anything
'''effort''' currently not aware of anything

Revision as of 09:30, 17 May 2012

Contents

The NetBeans Mercurial plugin should work with remote Filesytems

Problem description

Based on issue 195124 being fixed the time has approached to rewrite the NetBeans Mercurial plugin to work also with Remote Filesystems as well.

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 - in case scanning/indexing deals with remote sources

effort currently not aware of anything

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
  • status refresh relies on recursive listener. Is this going to work with remote FS?
  • ... and more is to be expected

effort 5-10dd

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

Due to the mentioned big amount of necessary changes regression is to be expected and should be thoroughly tested. Stabilization might drain resources as well.

Next Steps

TODO

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