Re: Summer of Code - Cached Packs/Object Lists

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

 



Please line wrap your email at something useful to others when
quoting, like 70-72 characters per line.

thisnukes4u@xxxxxxxxx wrote:
> I am particularly interested in the packfile caching project
> mentioned on the wiki, but I have a couple of questions:
>
> 1.  Would it be possible to implement both the packfile and
> object list caching mechanisms, or might would one interfere with
> the other in some way?

You could do both.  But I think most people on the list will argue
that doing both is overkill and only one is necessary, and further,
that only the one that offers the "biggest bank for the buck"
should be implemented.

Whole pack file caching has been discussed on list a few times as a
nice feature to have, but it raises some issues of cache management,
not to mention the issue I posed about it being relatively useless
on frequently changing repositories.

> 2.  With just a quick perusal of the daemon source, I noticed
> that it shells out to the upload-pack command. Where would it be
> appropriate to implement such a caching mechanism, in the daemon
> proper, the upload-pack code, or would both need to be updated?

The daemon doesn't get enough data from the client in order to
perform any sort of caching.

So the caching has to happen in upload-pack, and/or pack-objects.
(upload-pack forks out to pack-objects to create the pack file to
send to the client)

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

[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]

  Powered by Linux