|
The module tracks changes made on files in the IDE and provides an UI to view a files previous versions and to eventually revert a file to its older version.
The main features are:
The module provides no API.
The module is listening for events from the filesystem, stores files which where created, modified or deleted in the IDE and provides a UI to overview the stored data, revert old changes and to setup what files and for how long are to be hold in the local history.
Open Issues:
The module provides no API.
Question (arch-time): What are the time estimates of the work? Answer:Unit and functional tests.
Question (arch-where): Where one can find sources for your module? Answer:
The sources for the module are in NetBeans CVS in versioncontrol/localhistory directory.
These modules are required in project.xml:
No dependencies on 3rd party libraries.
Question (dep-platform): On which platforms does your module run? Does it run in the same way on each? Answer:The module is 100% pure Java and runs on any platform.
Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? Answer:Runs on 1.5.x.
Question (dep-jrejdk): Do you require the JDK or is the JRE enough? Answer:No JDK dependency known yet.
Only the module JAR is deployed.
Question (deploy-nbm): Can you deploy an NBM via the Update Center? Answer:Yes.
Question (deploy-shared): Do you need to be installed in the shared location only, or in the user directory only, or can your module be installed anywhere? Answer:The module may be installed anywhere.
Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public? Answer:No public packages
Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one, in addition to or instead of the normal module dependency declaration (e.g. tokens to require)? Answer:Nothing.
Yes.
Question (compat-standards): Does the module implement or define any standards? Is the implementation exact or does it deviate somehow? Answer:No standards defined or implemented.
Question (compat-version): Can your module coexist with earlier and future versions of itself? Can you correctly read all old settings? Will future versions be able to read your current settings? Can you read or politely ignore settings stored by a future version? Answer:Only one version of the module can be installed at a time. The settings are shared across different versions and will be read in future as well.
Question (compat-deprecation): How the introduction of your project influences functionality provided by previous version of the product? Answer:There are no previous versions.
java.io.File
directly?
Answer:
Yes. There are two main cases when the Local History creates or modifies files:
java.io.File
.
org.openide.filesystems.FileObject
as the (reverted) changes should be reflected in the IDE.
Yes, files are created for actions and window system layout. XXX
Question (resources-read): Does your module read any resources from layers? For what purpose? Answer:No.
Question (resources-mask): Does your module mask/hide/override any resources provided by other modules in their layers? Answer:No.
Question (resources-preferences): Does your module uses preferences via Preferences API? Does your module use NbPreferences or or regular JDK Preferences ? Does it read, write or both ? Does it share preferences with other modules ? If so, then why ? Answer:The module will read and write user options through NbPreferences. None of them will be shared with other modules.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
Yes. To get the action context for the context aware action.
Question (lookup-register): Do you register anything into lookup for other code to find? Answer: Yes. org.netbeans.modules.versioning.spi.VersioningSystem - it is looked up by the org.netbeans.modules.versioning.VersioningManager for delegating MFS events to the module. Question (lookup-remove): Do you remove entries of other modules from lookup? Answer:No.
System.getProperty
) property?
On a similar note, is there something interesting that you
pass to java.util.logging.Logger
? Or do you observe
what others log?
Answer:
No.
Question (exec-component): Is execution of your code influenced by any (string) property of any of your components? Answer:No.
Question (exec-ant-tasks): Do you define or register any ant tasks that other can use? Answer:No ant tasks provided.
Question (exec-classloader): Does your code create its own class loader(s)? Answer:No own classloaders.
Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer:No.
Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer:No.
Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer:No.
Question (exec-introspection): Does your module use any kind of runtime type information (instanceof
,
work with java.lang.Class
, etc.)?
Answer:
Yes. All type checks with instanceof
switching the control flow
are made only over module private types.
org.openide.filesystems.FileObject
layer. Any such data processing runs asynchronously
to the AWT thread.
Concurrent access to the local history storage is prevented by synchronizing all read and write acces to it, with the future option to eventually breakdown the granularity of synchronization to a finer level, if a synchronized access to the whole storage should prove as ineficient.
XXX Question (security-policy): Does your functionality require modifications to the standard policy file? Answer:No.
Question (security-grant): Does your code grant additional rights to some other code? Answer:No.
The Local History stores changed files by creating one-to-one copies from them. The module also stores some additional information in binary data files. The format ins't specified/stable yet, but they already may be regarded as private.
No ant build script.
Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop? Answer:None.
Question (format-clipboard): Which data flavors (if any) does your code read from or insert to the clipboard (by access to clipboard on means calling methods onjava.awt.datatransfer.Transferable
?
Answer:
None.
The Local History is supposed to store file versions only for a specified time period. Accordingly should be all obsolete local history entries removed when their age reaches a defined value. A possible solution to this would be running a cleanup task on every startup as a alternative to doning this just on demand for a accesed file or the whole storage.
XXX Question (perf-exit): Does your module run any code on exit? Answer:No.
Question (perf-scale): Which external criteria influence the performance of your program (size of file in editor, number of files in menu, in source directory, etc.) and how well your code scales? Answer:Generaly speaking - the amount and size of files in the local history storage will influence the performance of the Local History module. It is up to further evaluation how significant this impact will be in a reasonable configured environment (time period covered by local history, max size for stored files, ... ). XXX
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer:No explicit limits. Technically, the available memory size is the limit...
Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:The consumed memory will depend on:
see also perf-startup XXX
Question (perf-progress): Does your module execute any long-running tasks? Answer:There probably will be actions taking a recognizable amount of time. They will be processed asynchronously.
XXX Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas? Answer:No.
Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic? Answer:Yes, there probably will be actions rendering their enablement status depending on information dynamicaly retrieved from the local history storage. The exact list of candidates is not known yet. e.g. the "Revert Deleted" action should be enabled only for folders in which where files deleted for the time period covered by the local history.
XXX Question (perf-spi): How the performance of the plugged in code will be enforced? Answer:No plugged in code.
Built on December 20 2006. | Portions Copyright 1997-2006 Sun Microsystems, Inc. All rights reserved.