{"thread":{"id":"22568","subject":"[PATCH] Revert \"pack-objects: fix pack generation when using pack_size_limit\"","startedAt":"2010-02-08T15:39:01Z","lastAt":"2010-02-08T18:11:12Z","messageCount":3,"participants":["Nicolas Pitre","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"133926","messageId":"alpine.LFD.2.00.1002081032530.1681@xanadu.home","threadId":"22568","inReplyTo":null,"subject":"[PATCH] Revert \"pack-objects: fix pack generation when using pack_size_limit\"","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-08T15:39:01Z","receivedAt":"2010-02-08T15:39:01Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nThis reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.\n\nThat commit made the situation better for repositories with relatively\nsmall number of objects. However with many objects and a small pack size\nlimit, the time required to complete the repack tends towards O(n^2),\nor even much worse with long delta chains.\n\nSigned-off-by: Nicolas Pitre \n---\n\nFixing this doesn't appear to be as trivial as I initially thought.\nAlthough I do have some ideas, they're not appropriate so late in \nthe -rc period.\n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex dcfe62a..e1d3adf 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -445,13 +445,9 @@ static int write_one(struct sha1file *f,\n \tif (e->idx.offset || e->preferred_base)\n \t\treturn -1;\n \n-\t/*\n-\t * If we are deltified, attempt to write out base object first.\n-\t * If that fails due to the pack size limit then the current\n-\t * object might still possibly fit undeltified within that limit.\n-\t */\n-\tif (e->delta)\n-\t write_one(f, e->delta, offset);\n+\t/* if we are deltified, write out base object first. */\n+\tif (e->delta && !write_one(f, e->delta, offset))\n+\t\treturn 0;\n \n \te->idx.offset = *offset;\n \tsize = write_object(f, e, *offset);\n@@ -505,9 +501,11 @@ static void write_pack_file(void)\n \t\tsha1write(f, &hdr, sizeof(hdr));\n \t\toffset = sizeof(hdr);\n \t\tnr_written = 0;\n-\t\tfor (i = 0; i < nr_objects; i++)\n-\t\t\tif (write_one(f, objects + i, &offset) == 1)\n-\t\t\t\tdisplay_progress(progress_state, written);\n+\t\tfor (; i < nr_objects; i++) {\n+\t\t\tif (!write_one(f, objects + i, &offset))\n+\t\t\t\tbreak;\n+\t\t\tdisplay_progress(progress_state, written);\n+\t\t}\n \n \t\t/*\n \t\t * Did we write the wrong # entries in the header?\n@@ -582,7 +580,7 @@ static void write_pack_file(void)\n \t\t\twritten_list[j]->offset = (off_t)-1;\n \t\t}\n \t\tnr_remaining -= nr_written;\n-\t} while (nr_remaining);\n+\t} while (nr_remaining && i < nr_objects);\n \n \tfree(written_list);\n \tstop_progress(&progress_state);\ndiff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh\nindex 1058d98..7649b81 100755\n--- a/t/t5300-pack-object.sh\n+++ b/t/t5300-pack-object.sh\n@@ -389,7 +389,7 @@ test_expect_success 'verify resulting packs' '\n test_expect_success 'tolerate packsizelimit smaller than biggest object' '\n \tgit config pack.packSizeLimit 1 &&\n \tpackname_11=$(git pack-objects test-11 writes:\n\n> This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.\n>\n> That commit made the situation better for repositories with relatively\n> small number of objects. However with many objects and a small pack size\n> limit, the time required to complete the repack tends towards O(n^2),\n> or even much worse with long delta chains.\n>\n> Signed-off-by: Nicolas Pitre \n> ---\n>\n> Fixing this doesn't appear to be as trivial as I initially thought.\n> Although I do have some ideas, they're not appropriate so late in \n> the -rc period.\n\nOk, so the idea is what a2430dd tried is an issue worth addressing but the\nparticular execution wasn't good? We revert it for now, but we will try\nagain after the release, perhaps doing it differently?\n\nI agree with it if that is your intention, but \"Most of\" bugs me a bit.\n"},{"id":"133936","messageId":"alpine.LFD.2.00.1002081306420.1681@xanadu.home","threadId":"22568","inReplyTo":"7v3a1bpqqq.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert \"pack-objects: fix pack generation when using pack_size_limit\"","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-08T18:11:12Z","receivedAt":"2010-02-08T18:11:12Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 8 Feb 2010, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.\n> >\n> > That commit made the situation better for repositories with relatively\n> > small number of objects. However with many objects and a small pack size\n> > limit, the time required to complete the repack tends towards O(n^2),\n> > or even much worse with long delta chains.\n> >\n> > Signed-off-by: Nicolas Pitre \n> > ---\n> >\n> > Fixing this doesn't appear to be as trivial as I initially thought.\n> > Although I do have some ideas, they're not appropriate so late in \n> > the -rc period.\n> \n> Ok, so the idea is what a2430dd tried is an issue worth addressing but the\n> particular execution wasn't good? We revert it for now, but we will try\n> again after the release, perhaps doing it differently?\n\nExact. I did try a few things in the hope that the \"fix\" would have \nbeen trivial enough to merge now but none of that worked satisfactorily.\n\n> I agree with it if that is your intention, but \"Most of\" bugs me a bit.\n\nIt's not a straight revert in the sense that I left in some cleanups and \nleft out the redundant self consistency check. Only the significant \nparts were reverted.\n\n\nNicolas\n"}]}