From: Alex Riesen Date: Fri, 27 Oct 2006 08:08:17 GMT Subject: Re: fetching packs and storing them as packs Message-ID: <81b0412b0610270108t7b93d04y2c99be20b7f41387@mail.gmail.com> In-Reply-To: <20061027075229.GD29057@spearce.org> >> >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? On 10/27/06, Shawn Pearce wrote: > Alex Riesen wrote: > > >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. > > The contents of the new pack must be accessable as a normal pack > before we update and unlock the refs that are being changed. This > means it must be a normal pack in $GIT_DIR/objects/pack. > > Currently all packs under $GIT_DIR/objects/pack are deleted during > `repack -a -d`. Those packs may have been added to that directory > after the repack started resulting in them getting deleted when > the repack completes, but with none of their contained objects in > the newly created pack. Thus the repository is suddenly missing > everything that was just pushed (or fetched). > > -- > Shawn.