From: Linus Torvalds <torvalds@osdl.org>
To: Keith Packard <keithp@keithp.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Repacking many disconnected blobs
Date: Wed, 14 Jun 2006 11:18:15 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0606141113130.5498@g5.osdl.org> (raw)
In-Reply-To: <1150307715.20536.166.camel@neko.keithp.com>
On Wed, 14 Jun 2006, Keith Packard wrote:
> On Wed, 2006-06-14 at 08:53 -0700, Linus Torvalds wrote:
>
> > - You can list the objects with "most important first" order first, if
> > you can. That will improve locality later (the packing will try to
> > generate the pack so that the order you gave the objects in will be a
> > rough order of the resul - the first objects will be together at the
> > beginning, the last objects will be at the end)
>
> I take every ,v file and construct blobs for every revision. If I
> understand this correctly, I should be shuffling the revisions so I send
> the latest revision of every file first, then the next-latest revision.
> It would be somewhat easier to just send the whole list of revisions for
> the first file and then move to the next file, but if shuffling is what
> I want, I'll do that.
You don't _need_ to shuffle. As mentioned, it will only affect the
location of the data in the pack-file, which in turn will mostly matter
as an IO pattern thing, not anything really fundamental. If the pack-file
ends up caching well, the IO patterns obviously will never matter.
Eventually, after the whole import has finished, and you do the final
repack, that one will do things in "recency order" (or "global
reachability order" if you prefer), which means that all the objects in
the final pack will be sorted by how "close" they are to the top-of-tree.
And that will happen regardless of what the intermediate ordering has
been.
So if shuffling is inconvenient, just don't do it.
On the other hand, if you know that you generated the blobs "oldest to
newest", just print them in the reverse order when you end up repacking,
and you're all done (if you just save the info into some array before you
repack, just walk the array backwards).
Linus
next prev parent reply other threads:[~2006-06-14 18:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-14 7:17 Repacking many disconnected blobs Keith Packard
2006-06-14 7:29 ` Shawn Pearce
2006-06-14 9:07 ` Johannes Schindelin
2006-06-14 12:33 ` Junio C Hamano
2006-06-14 9:37 ` Sergey Vlasov
2006-06-14 15:53 ` Linus Torvalds
2006-06-14 17:55 ` Keith Packard
2006-06-14 18:18 ` Linus Torvalds [this message]
2006-06-14 18:52 ` Linus Torvalds
2006-06-14 18:59 ` Keith Packard
2006-06-14 19:18 ` Linus Torvalds
2006-06-14 19:25 ` Nicolas Pitre
2006-06-14 21:05 ` Keith Packard
2006-06-14 21:17 ` Linus Torvalds
2006-06-14 21:20 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0606141113130.5498@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=keithp@keithp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).