MakeHgPluginRemoteFSAware

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 (or even more) 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. Now there might be one local and more remote clients. Need to figure out how that is supposed to work.
  • the plugin honors the os-wide {$userdir}/hgrc file. Now there will be more instances (local, and who knows how many remote ones) 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-15dd and more

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:

  • reimplementing and implementing
  • ensuring quality
  • taking over future responsibility


  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 backed by VCS Team if necessary
  5. Other issues - CND Team backed by VCS Team if necessary
  6. Other APIs - VCS Team (can be done in parallel to the other steps)
  7. merge - note that a statement from QE will be necessary before merging the changes to trunk
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