Re: [PATCH] handle concurrent pruning of packed objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 02, 2006 at 08:53:52AM -0700, Junio C Hamano wrote:

> I am uncertain about not re-examining the packs it originally
> thought it had.  By prepending the new ones (and the same old
> surviving ones) at the beginning you are effectively hiding the
> old packs, which sounds reasonable in the usual case.

That shouldn't make a difference for correctness, even if the old packs
are still there. If you have an object in two packs, then it doesn't
matter which one you pull it from. The main impacts I can think of are:
  1. The old pack may already be mapped, and it would be more efficient
     to use it. However, the new pack will be mapped on first use, so it
     will be used from then on.
  2. The pack list can grow without bound. However, for this to matter,
     you'd have to do many prunes during the course of a single git
     command.

> Also I suspect this might have funny interaction with the case
> where there are hand-added packs (see how verify-pack does it).
> We do not silently "fix" missing object problems we discover
> there.

I will take a look at this.

-Peff
-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]