MakeHgPluginRemoteFSAware

(Difference between revisions)
m (Other APIs)
(Other APIs)
 
(34 intermediate revisions not shown)
Line 2: Line 2:
==Problem description==
==Problem description==
-
Based on [http://netbeans.org/bugzilla/show_bug.cgi?id=195124 issue 195124] being fixed the time has approached to rewrite the NetBeans Mercurial plugin to work also with Remote Filesystems as well.
+
Now, after [http://netbeans.org/bugzilla/show_bug.cgi?id=195124 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==
==Necessary actions==
Line 16: Line 23:
Note that while this seems to be trivial thanks to <code>extexecution</code>, some minor issues will have to be resolved - e.g.:
Note that while this seems to be trivial thanks to <code>extexecution</code>, 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.
+
* 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===
===File type===
Line 30: Line 37:
===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
+
* 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 <code>io.File</code> 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
-
'''effort''' currently not aware of anything
+
* Integration with bugtracking - based on <code>io.File</code> - e.g. issue hyperlinks and commit hooks. '''effort''' 1-3dd
===Other issues===
===Other issues===
deal with other specific problems caused by the plugin being written only for local usage - e.g.:
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.
+
* 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 two instances (local, remote) of the config file. Has to be properly handled depending on remote or local usecase.
+
* 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
* remote FS aware FileChoosers have to be used where necessary
-
* status refresh relies on recursive listener. Is this going to work with remote FS?
+
* background status refresh relies on recursive listener. Is this going to work with remote FS?
* ... and more is to be expected
* ... and more is to be expected
-
'''effort''' 5-10dd
+
'''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===
===Performance===
Line 48: Line 61:
===Testing===
===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.
+
* 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==
==Next Steps==
-
'''TODO'''
+
Join forces in:
 +
* reimplementing and implementing
 +
* ensuring quality
 +
* taking over future responsibility
 +
 
 +
 
 +
 
 +
# create branch
 +
# switch the SPI and do a simple implementation for one FS event - VCS Team
 +
# command execution - CND Team
 +
# file type change - CND Team backed by VCS Team if necessary
 +
# Other issues - CND Team backed by VCS Team if necessary
 +
# Other APIs - VCS Team (can be done in parallel to the other steps)
 +
# merge - note that a statement from '''QE''' will be necessary before merging the changes to trunk

Current revision as of 12:21, 21 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 (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