This revision was automatically updated to reflect the committed changes.
Closed by commit rHG891118dcd279: bundle2: seek part back during iteration
(authored by durham).
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST UPDATE
https://phab.mercurial-scm.org/D289?vs=1216&id=1228
REVISION DETAIL
durham updated this revision to Diff 1216.
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST UPDATE
https://phab.mercurial-scm.org/D289?vs=659&id=1216
REVISION DETAIL
https://phab.mercurial-scm.org/D289
AFFECTED FILES
mercurial/bundle2.py
mercurial/bundlerepo.py
CHANGE DETAILS
diff --git
durham added a comment.
I agree it's brittle, but no more brittle than before, since we still had to
seek back.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D289
To: durham, #hg-reviewers, indygreg
Cc: martinvonz, indygreg, mercurial-devel
martinvonz added inline comments.
INLINE COMMENTS
> bundle2.py:811
> +# code consuming this generator has a part that starts at 0.
> part.seek(0, 2)
> +part.seek(0)
Unrelated to this patch, but seems like we should define constants for
"whence". I don't thin
indygreg accepted this revision.
indygreg added a comment.
This revision is now accepted and ready to land.
This change feels a bit brittle to me, as it is relying on low-level
implementation details of how bundle2 part handling and underlying stream
consumption works. But I know from trying
durham created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.
REVISION SUMMARY
Previously, iterparts would yield the part to users, then consume the part.
This
changed the part after the user was given it and left it at the end, both of
whi
