[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jgit-dev] Upcoming 2.1 git-gc feature
- From: Shawn Pearce <spearce@xxxxxxxxxxx>
- Date: Thu, 6 Sep 2012 07:00:25 -0700
- Delivered-to: firstname.lastname@example.org
On Thu, Sep 6, 2012 at 5:19 AM, <james.moger@xxxxxxxxxxx> wrote:
> Interesting. I look forward to trying it out.
> So far I have not been able to (native) GC a running Gitblit server on
> Windows; Linux _seems_ to work alright. I suppose this is a Windows
> sharing violation or something like that. Git complains about:
> rm: cannot unlink 'pack-yadayadayadayada.pack': Permission denied
> Perhaps I am being naive to hope that I can GC an open repository -- but
> that would be cool. One less thing for Gitblit users to have to
> (periodically) think about.
This should work correctly using the Java implementation of GC. JGit
keeps pack files open if they have been recently accessed, trying to
avoid the costs of the close/open system calls. This of course
confuses the C implementation, because Windows won't permit a file to
be deleted while it is open. The Java implementation of GC is aware of
this and forces JGit to close that file handle before it attempts to
delete the now unnecessary pack file... assuming the reader and the GC
were using the same Repository instance. Which is why we have that
RepositoryCache, to simplify making sure every thread is using the
same Repository instance inside of the JVM.
Linux should work fine even with the native git gc because its OK to
delete a file while its in-use. Eventually ObjectDirectory will notice
the file is no longer in the packs directory and release the open file
handle, permitting the inode to be released from the file system.