Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] isOutdated() and lastModified()

12 dec 2010 kl. 04:50 skrev Shawn Pearce:

> 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
>>> call (at least in isOutdated() method).
>>> For my Sun Java and OpenJDK 1.6.0 (Debian squeeze/sid)
>>> 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.

We cache a timestamp internally. We could add one to notice the last
time we checked, or use the current one (last modified) differently, so I
do not think we need a new file for that. Command line JGit will need to
read the refs anyway. But I think you are right that we should modify this. I
did not read Dmitry's message close enough.

> 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.

That was a different story. The idea was to avoid a stat call to check the
length of a file against the cached information in the index, but assuming
that a if the length changed, then the timestamp would too. The three seconds
come from the file system with the lowest timestamp resolution of two seconds.
For refs we don't check the length at all, so there is no extra stat to avoid.

-- robin

Back to the top