Re: Resumable clone

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

 



Junio,

> Yes, that is very close to what I said in the "what remains?"
> section, but with a crucial difference in a detail.  Perhaps reading
> the message you are respoinding to again more carefully will clear
> the confusion.  This is what we want to allow the server to say
> (from the message you are responding to, but rephrased slightly,
> hoping that it would help unconfuse you):
>
>     I prefer not to serve a full clone to you in the usual route if
>     I can avoid it.  You can help me by populate your history first
>     with something else (which would bring you to a state as if you
>     cloned potentially a bit older version of me) and then coming
>     back to me for an additional fetch to complete the history.
>
> That "something else" does not have to be, and is not expected to
> be, the "full" history of the current state.  As long as it can be
> used to bring the cloner to a reasonably recent state, sufficient to
> make a follow up incremental fetch inexpesive enough, it is
> appropriate.

Sorry, I was thrown off by:

> - the type of resource, if we want this to be extensible.  I
>   think we should initially limit it to "a single full history
>   .pack",

I misinterpreted what you meant by "a single full history .pack," and
used that to limit what you said earlier. A lot of my reasoning from
there misses the point, then, because it involved finding some way to
determine if a history .pack contains the full history, which
obviously is irrelevant.

>> I'm not sure how the server should determine the returned resource. A
>> packfile alone does not guarantee the full repo history, and I'm not
>> positive checking the idx file for HEAD's commit hash ensures every
>> sub-object is in that file (though I feel it should, because it is
>> delta-compressed).
>
> The above reasoning does not make much technical sense.  delta
> compression does not ensure connectivity in the commit history and
> commit->tree->blob containment.  Again I am not sure where you are
> going with this.

Related to the above, I was trying to find a way to determine if the
packfile contained the full history, which actually doesn't matter. My
technical reasoning was affected by the way deltas represent changes
in other VCS's, but I realize now that git's delta compression is
based around the similarity of objects, not their historical relation
to each other.

>> Which leaves me with questions on how to test the above condition. Is
>> there an expected place, such as config, where the user will specify
>> the type of alternate resource, and should we assume some default if
>> it isn't specified? Can the user optionally specify the exact file to
>> use (I can't see why because it only invites more errors)? Should the
>> specification of this option change git's behavior on update, such as
>> making sure the full history is compressed? Does the existence of the
>> HEAD object in the packfile ensure the repo's entire history is
>> contained in that file?
>
> Those (except for your assumption that no follow-up fetch is
> allowed, which requires you to limit yourself to "full" history,
> which is an unnecessary requirement) are good points one should be
> making design decisions on when building this part of the system.

Awesome, all of this is enough info to get me started. Thanks!

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