>> >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 <spearce@spearce.org> wrote: > Alex Riesen <raa.lkml@gmail.com> 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. > - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Oct 27 18:08:26 2006
This archive was generated by hypermail 2.1.8 : 2006-10-27 18:09:16 EST