On Fri, Feb 1, 2013 at 1:14 AM, Jeff King wrote:
> On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
>
>> >> - System resource cost we incur by having to keep 50 file
>> >>descriptors open and maintaining 50 mmap windows will reduce by
>> >>50 fold.
>> >
>> > I wonder how m
On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
> >> - System resource cost we incur by having to keep 50 file
> >>descriptors open and maintaining 50 mmap windows will reduce by
> >>50 fold.
> >
> > I wonder how measurable that is (and if it matters on Linux versus less
On Tue, Jan 29, 2013 at 1:19 PM, Jeff King wrote:
> On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote:
>
>> The point is not about space. Disk is cheap, and it is not making
>> it any worse than what happens to your target audience, that is a
>> fetch-only repository with only "gc --
Jeff King writes:
>> > But how do these somewhat mediocre concatenated packs get turned into
>> > real packs?
>>
>> How do they get processed in a fetch-only repositories that
>> sometimes run "gc --auto" today? By runninng "repack -a -d -f"
>> occasionally, perhaps?
>
> Do we run "repack -adf"
On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote:
> The point is not about space. Disk is cheap, and it is not making
> it any worse than what happens to your target audience, that is a
> fetch-only repository with only "gc --auto" in it, where nobody
> passes "-f" to "repack" to ca
Jeff King writes:
>> I also wonder if we would be helped by another "repack" mode that
>> coalesces small packs into a single one with minimum overhead, and
>> run that often from "gc --auto", so that we do not end up having to
>> have 50 packfiles.
>> ...
>
> I'm not sure. If I understand you co
Jeff King wrote:
>On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
>
>> Both makes sense to me.
>>
>> I also wonder if we would be helped by another "repack" mode that
>> coalesces small packs into a single one with minimum overhead, and
>> run that often from "gc --auto", so th
On Sun, Jan 27, 2013 at 1:32 PM, Junio C Hamano wrote:
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having to
> have 50 packfiles.
>
> When we hav
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
> Both makes sense to me.
>
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having t
On Sat, Jan 26, 2013 at 10:32 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> This is a repost from here:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/211176
>>
>> which got no response initially. Basically the issue is that read-only
>> repos (e.g., a CI server) whose workfl
Jeff King writes:
> This is a repost from here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/211176
>
> which got no response initially. Basically the issue is that read-only
> repos (e.g., a CI server) whose workflow is something like:
>
> git fetch $some_branch &&
> git chec
This is a repost from here:
http://thread.gmane.org/gmane.comp.version-control.git/211176
which got no response initially. Basically the issue is that read-only
repos (e.g., a CI server) whose workflow is something like:
git fetch $some_branch &&
git checkout -f $some_branch &&
make test
12 matches
Mail list logo
