Re: fetching packs and storing them as packs

From: Shawn Pearce <spearce@spearce.org>
Date: Oct 27, 2006, 08:13 UTC
Message-ID: <20061027081343.GE29057@spearce.org>
In-Reply-To: <81b0412b0610270108t7b93d04y2c99be20b7f41387@mail.gmail.com>

Alex Riesen <raa.lkml@gmail.com> wrote:

Show 10 quoted lines

> >>>So the receive-pack process becomes:
> >>>
> >>> a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> >>>b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
> >>
> >>Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
> >
> >Because there is a race condition.
> 
> Oh, right. Incidentally, is there a lockfile for packs?

No, we have never needed them before. And I think we'd like to avoid adding them now.

We do have the rule that a pack can only be accessed if its .idx file exists; therefore we generate a pack and its index, then place the pack into the object directory, then the index. That way the pack is there before the index but another process won't attempt to read the pack until the index exists. It also means we should never put an index into the pack directory before its associated pack. :-)

If we are pruneing packs or loose objects after the repack we delete only after the pack and index are in place. Running processes rescan the existing packs once if they look for an object and cannot find it in the loose objects directory or in the packs it already knows about; this lets most running processes automatically recover should a parallel repack delete the loose objects it needs (as they were just packed).