>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@xxxxxxxxxxx> wrote:
Alex Riesen <raa.lkml@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html