Re: [jgit-dev] isOutdated() and lastModified()

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Sat, Dec 11, 2010 at 8:23 AM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
> 11 dec 2010 kl. 17:02 skrev Dmitry Pavlenko:
>
>> I seems that FileBasedConfig (and loose-refs-related classes) relies on
>> java.io.File.lastModified() call (at least in isOutdated() method).
>>
>> For my Sun Java 1.6.0.22 and OpenJDK 1.6.0 (Debian squeeze/sid)
>> java.io.File.lastModified() can be the same after changes in the file.
>>
>> I don't know is it expected, is it JDK bug, or JGit problem. Do you?
>
> This is expected. If the changes are quick enough, the clock will not step forward in
> between.
...
> There is a workaround for this in JGit and the original C Git, aka "racy git", which means
> that we sometimes need to read the file to check if it has changed.

I wonder if we can't use DirCache to help us with the config and
packed-refs files, and their "racy git" update problems.  If we create
$GIT_DIR/config.index as a standard DirCache format with only two
files in it (config and packed-refs), we can use the cached stat
information in that file to tell us if config or packed-refs is racily
clean.  If it is, we can read the files again.  We might even be able
to use it for the loose ref files, to try and catch them being racily
clean too.

Another idea is to use what you suggested before somewhere else (I'm
sorry I can't recall where this is)... if the file modification time
is less than 3 seconds different from the last time we read the file,
consider it outdated and read the file again anyway.

-- 
Shawn.