push performance..

[Robert Collins]

On Thu, 2006-08-17 at 17:47 -0500, John Arbash Meinel wrote:
> Robert Collins wrote:
> > So one reason push is slow is because of this:
> > 
> > say the remote repo is at revision A
> > 
> > I branched from revision B, did a local change C, then merge from the
> > remote repo committing that as D.
> > 
> > The revision parents are:
> > A: [B]
> > B: []
> > C: [B]
> > D: [C, A]
> > 
> > Now I do a push, which we hope would only push the unique content for C,
> > and D.
> > 
> > What happens though, is that all the files altered by A are listed in
> > the commit of D as a diff against C. So if this commit A altered many
> > files, pushing D ends up checking all those files indexes for the
> > presence of their revisions even though the revision A is presumed to be
> > fully installed in the remote repository.
> > 
> > I proposed that we filter the fileids which we will check by the
> > revisions we know to be be fully installed in the remote repository, and
> > if there are no interesting revisions left for a given fileid, we dont
> > bother checking it.
> > 
> > -Rob
> 
> I'm not sure how you exactly derived this, and I'm not sure that I
> follow why there are markers for every change in A inside D.

When we record D we create a knit delta from C to D. The inventory delta
from C to D includes all the changes from B to A, because D was a merge
of A, and C did not have A in its ancestry.

> Is it just something about file_ids_affected_by?

It is. It looks like it should be right, so I'll need to do a pdb run to
verify this. Basically though, it seems to me that the text fetching
phase takes way too long to push over sftp. 

> Are you sure it isn't that we are calling file_ids_affected_by, and
> including revision id 'A', even though it is the remote target?

Nope, not sure yet.

> Either way, filtering out the entries that haven't truly been modified
> since A seems fine.
> 
> Or maybe you are saying that we need to push a new entry for all of
> these entries, but we don't need to read the old index first.

I was saying the former, but its true that we could just punt and append
to the index because its not expected that they would already have texts
from the revision we are pushing.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060818/4c294568/attachment.pgp