Thread (19 messages) flat view 19 messages, 3 authors, 2017-09-29

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

From: Jeff Hostetler <hidden>
Date: 2017-09-26 14:25:21


On 9/22/2017 6:58 PM, Jonathan Tan wrote:
On Fri, 22 Sep 2017 17:32:00 -0400
Jeff Hostetler [off-list ref] wrote:
quoted
I guess I'm afraid that the first call to is_promised() is going
cause a very long pause as it loads up a very large hash of objects.
Yes, the first call will cause a long pause. (I think fsck and gc can
tolerate this, but a better solution is appreciated.)
quoted
Perhaps you could augment the OID lookup to remember where the object
was found (essentially a .promisor bit set).  Then you wouldn't need
to touch them all.
Sorry - I don't understand this. Are you saying that missing promisor
objects should go into the global object hashtable, so that we can set a
flag on them?
I just meant could we add a bit to "struct object_info" to indicate
that the object was found in a .promisor packfile ?  This could
be set in sha1_object_info_extended().

Then the is_promised() calls in fsck and gc would just test that bit.

Given that that bit will be set on promisOR objects (and we won't
have object_info for missing objects), you may need to adjust the
iterator in the fsck/gc code slightly.

This is a bit of a handwave, but could something like that eliminate
the need to build this oidset?

quoted
quoted
The oidset will deduplicate OIDs.
Right, but you still have an entry for each object.  For a repo the
size of Windows, you may have 25M+ objects your copy of the ODB.
We have entries only for the "frontier" objects (the objects directly
referenced by any promisor object). For the Windows repo, for example, I
foresee that many of the blobs, trees, and commits will be "hiding"
behind objects that the repository user did not download into their
repo.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help