push performance..

[John Arbash Meinel]

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.

Is it just something about file_ids_affected_by?

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?

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.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060817/d3ef4b9f/attachment.pgp