i'd like to ask for a review for a planed local history module.
The module tracks changes made on files in the IDE and provides an UI to:
- view previously saved versions from a file
- to revert a file to some from its older versions
for more information see the answered architecture questions in branch localhistory
Created attachment 36803 [details]
Architecture Answers for Local History module
Y01 Few times the document says, that there is no API. Usually we consider
something some other module can depend on being an API, so there is an API. It
is the location of the local storage, preferences, etc. So I would say "There
is no stable API"
Y02 One of the open questions is where to store the storage. I would say it
should be under $userdir (which means that NetBeans 5.5 and NetBeans 6.0 are
not going to share this storage), this similifies the versioning I guess. The
storage shall not be $userdir/config as that is an area to be accessed by
FileObjects while the storage is supposed to be handled directly by
java.io.File access. I would personally prefer $userdir/cache/localstorage.
Y03 Please use <api group="java.io.File" .../> to describe the location and
format of the storage. Please make sure that one of the main storage files
contains some version string, so you can detect that the cache is of old
format and delete it in future if needed.
Y04 There is a note about using lookup for own actions. Do you subclass some
SystemAction subclass or do you implement your own actions. Can you give me
links to source files?
Y05 Contracts imported from versioning module should be marked as <api
type="import" category="friend" .../> as you are probably a friend of
Y06 There were some notes about performance (especially doing cleanup of the
cache on startup), that might be interesting to Radim & co.
Y07 Imho you should have a TCR (a P2 bug) reported against versioning module
to switch to new contract provided by masterfs that will allow you to be
notified "before file change". Imho masterfs owner shall agree that he
implements such contract (a P2 for masterfs).
Otherwise ok and I am looking forward to see this in the build I use daily.
actions used for the context menu in explorer are NodeAction subclasses,
the remaining ones, used in the localhistoryview are SystemActions
see in branch localhistory, project folder versioncontrol/localhistory/
all actions are in package org.netbeans.modules.localhistory.ui.actions
the mentioned lookup is created in
since yesterday there are a few more usages of lookups also in
i must admint i'm not sure if the cleanup on startup is the best idea.
it's still open when it should be triggered (startup, on demand, ...).
However, i agree that localhistory should be a candidate for Radim & co.
Y07 I can't promise notification before file change, just can notify you that
OutputStream was issued.
my previous commit - typo in Y04:
> the remaining ones, used in the localhistoryview are SystemActions
the remaining ones, used in the localhistoryview are _no SystemActions_
Actually I found two that subclass NodeAction, like
and two that directly subclass AbstractAction, like
I guess the use of NodeAction is ok. I suggest you register the action into a
systemfilesystem folder like Actions/Versioning/LocalHistory/ or so. As a
result it would be possible for users to put those actions into toolbar,
assign shortcuts to them etc.
However this causes a problem with your non-NodeActions. They should implement
ContextAwareAction and find the files they need to operate on from Lookup.
I'll send you a sample code.
re startup impact: I guess that every startup will be affected a bit but if we
can manage it reasonably it can be OK. Let's measure how long it is. I do not
expect large amount of data like in
Reassigning issue to "localhistory" component.
Y01 - Y05 - changed in arch.xml and code
Y07 - issue #92671, issue #92676