"Shawn O. Pearce" [off-list ref] writes:
quoted
quoted
Are you fetching from a configured remote that has tracking branches,
or are you fetching through a one-shot URL pasted onto the command
line?
Configured remote.
Hmm. I wonder if we should try to shortcut the commit walking in
a case like this and just feed the tracking branches we already have.
You mean that the main culprit is the presense of thousdands of commits
that fetcher has obtained through the other remotes (and his own) that the
uploader makes fetcher walk all the way, in the false hope that there
might be a commit among them that is closer to the commits being fetched
than the ones at the tip of tracking branch the fetcher has for this
uploader currently?
And the solution might be to tell only about the tips of remote tracking
branches fetcher has obtained from this particular uploader, not about
other remote tracking bracnesh it got from others or his own local
branches (which may have merged from other remotes)?
It is a clever idea but I suspect it may not work well in practice. For
example, suppose a project is two-tier, say, with top-level and subsystem
repositories, the former of which regularly merge from the latter, and you
are a participant primarily working on the subsystem. You fetch daily
from the subsystem repository, but weekly from the top-level.
Now, when you fetch from the top-level, the remote tracking refs you have
for it are much more stale than your other refs. The top-level would have
acquired a lot more commits from the same subsystem repository since you
fetched from there the last time, and you already have many of them
through your daily fetch from the subsystem repository. To minimize the
transfer in such a case, the fetcher does want to tell the uploader that
it has those commits from the same subsystem repository, so that the
commit walker can stop at a recent merge into the top-level from the
subsystem repository.
There was a discussion about updating the commit walk exchange to bisect
the history (skip and try a much older one to see if it is reachable, but
to avoid overshooting, step back and see if a newer one is still common).
It would be a lot more work and needs to be implemented as a new protocol
capability, but I think it is the right way to go in the longer term.
On Thu, Jan 21, 2010 at 09:42:36AM -0800, Junio C Hamano wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
quoted
quoted
Are you fetching from a configured remote that has tracking branches,
or are you fetching through a one-shot URL pasted onto the command
line?
Configured remote.
Hmm. I wonder if we should try to shortcut the commit walking in
a case like this and just feed the tracking branches we already have.
You mean that the main culprit is the presense of thousdands of commits
that fetcher has obtained through the other remotes (and his own) that the
uploader makes fetcher walk all the way, in the false hope that there
might be a commit among them that is closer to the commits being fetched
than the ones at the tip of tracking branch the fetcher has for this
uploader currently?
And the solution might be to tell only about the tips of remote tracking
branches fetcher has obtained from this particular uploader, not about
other remote tracking bracnesh it got from others or his own local
branches (which may have merged from other remotes)?
It is a clever idea but I suspect it may not work well in practice. For
example, suppose a project is two-tier, say, with top-level and subsystem
repositories, the former of which regularly merge from the latter, and you
are a participant primarily working on the subsystem. You fetch daily
from the subsystem repository, but weekly from the top-level.
Now, when you fetch from the top-level, the remote tracking refs you have
for it are much more stale than your other refs. The top-level would have
acquired a lot more commits from the same subsystem repository since you
fetched from there the last time, and you already have many of them
through your daily fetch from the subsystem repository. To minimize the
transfer in such a case, the fetcher does want to tell the uploader that
it has those commits from the same subsystem repository, so that the
commit walker can stop at a recent merge into the top-level from the
subsystem repository.
There was a discussion about updating the commit walk exchange to bisect
the history (skip and try a much older one to see if it is reachable, but
to avoid overshooting, step back and see if a newer one is still common).
It would be a lot more work and needs to be implemented as a new protocol
capability, but I think it is the right way to go in the longer term.
I thought about this some more: it seems that nothing in
pack-protocol.txt dictates that client has to send have
lines in order. The whole logic would be on client side.
So a new capability will be there just in case we find a use for a
server-side optimization later on, we don't need the client to behave
differently in any way when this capability is enabled/disabled.
Right?
--
MST