search

denio7 / egit

Automatically exported from code.google.com/p/egit
0 stars 0 forks source link

Support for pluggable file event monitoring #40

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
JGit has been created initially to work inside an IDE. Since IDE sessions
are long-lived and JGit tends to cache .git repository state files in
memory to improve performance, a problem of consistency may arise if the
user modifies the .git repository outside of the IDE.

Many IDEs provide file event APIs, libraries exist for using inotify from
Java, and the Java core might someday support watching file resources
(JSR 203). JGit should provide an optional API for using these service
to improve consistency with in-memory and on-disk representations.

This could help to fix issue 2 and issue 31.

Resources:

 - Example of using the NetBeans File Event API:

http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesys
tems/doc-files/api.html#events

Original issue reported on code.google.com by jonas.fonseca on 20 Sep 2008 at 10:22

GoogleCodeExporter commented 8 years ago 
With the right API and usage design, JGit should be able to handle monitoring
out-of-the-box in a somewhat resource constraint way. The quoted issues mentions
using file modification timestamps, so if the API allows to both mark files
"dirty" and provide an on-demand check dirty state method, it should be able
to work both with monitoring:

 - using real events received at anytime, in which case the internal cache could
   be reloaded or simply cleared for later on-demand reloading.

 - using timestamp based method, where each access forces a dirty state check or
   where a background timer emulates and triggers "real events" by continuously
   doing the checking at predefined intervals.

Original comment by jonas.fonseca on 20 Sep 2008 at 11:07

GoogleCodeExporter commented 8 years ago 
Should this really be in Jgit? from what I saw in the code separation it seems 
JGit is a git library with a stand alone command line program 

The library part of JGit is reused in EGit. 

It's the EGit use case which implies long lived sessions, the JGit command line 
program has short lived sessions.

Original comment by jean.he...@gmail.com on 13 Nov 2008 at 9:13

GoogleCodeExporter commented 8 years ago 
This might not be something that necessarily fits into the
core of JGit. But I think that it is something EGit and
NbGit (the NetBeans Git plugin) needs to deal with, which
in my opinion merits an API for more "managed" resources.
Could be a separate library.

Original comment by jonas.fonseca on 13 Nov 2008 at 10:24

GoogleCodeExporter commented 8 years ago 
The primary focus of jgit was, and IMHO, is, to support IDE's. That should not
preclude short lived processes so whenever necessary that has to be taken into
account when designing API's. 

Subscription mechanisms shouldn't be activated until someone requests them and a
command line API shouldn't request subscriptions. I'm not sure we follow that 
rule,
but we should.

Original comment by robin.ro...@gmail.com on 16 Nov 2008 at 6:14

GoogleCodeExporter commented 8 years ago 
Note that the Eclipse filesystem monitoring API doesn't actually monitor the 
file system; instead, the Eclipse 
view is of the set of files/timestamps. So the Eclipse API would only notice if 
the file was modified by 
Eclipse, which probably precludes the editing-outside concept.

When Eclipse notices that a file editor is out of date, it does so by checking 
the file's timestamp agianst the 
last known timestamp, and prompting a warning if it's out.

Various operating systems do have APIs for notifying when a file is changed, 
but these aren't integrated into 
Eclipse at a great level at the moment. 

What I'd suggest is checking the timestamp for the configuration when doing 
access, and then if it's 
different from last time, reloading. However, this might be an expensive 
operation so it might only be worth 
doing if the last access was (say) 5 mins ago.

Original comment by alex.ble...@gmail.com on 18 Apr 2009 at 9:44

GoogleCodeExporter commented 8 years ago 
We scan for changes both as-needed and regularly. The git index and refs are 
looked
at, by timestamp, to see if there are changes every few seconds and we also 
check the
timestamp on-access for refs and index. 

For the config we could add it to the scan loop so the object access API can 
pick up
changes (we don't want to do it for every object access), plus an on-demand 
lookup
when editing.

Original comment by robin.ro...@gmail.com on 19 Apr 2009 at 9:53

GoogleCodeExporter commented 8 years ago 
> We scan for changes both as-needed and regularly.

...but not when a project was explicitly closed and then reopened.
http://egit.eclipse.org/r/108 implements reloading of a git config's content on 
a
project open event.

Original comment by mykola.nickishov on 17 Nov 2009 at 2:22

GoogleCodeExporter commented 8 years ago 
Looks like https://bugs.eclipse.org/bugs/show_bug.cgi?id=295661

Original comment by robin.ro...@gmail.com on 13 Jul 2010 at 8:32