lib/model, gui: Correct completion percentages when there are lots of deletes (fixes #3496) #3556
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… deletes (fixes #3496) We used to consider deleted files & directories 128 bytes large. After the delta indexes change a bug slipped in where deleted files would be weighted according to their old non-deleted size. Both ways are incorrect (but the latest change made it worse), as if there are more files deleted than remaining data in the repo the needSize can be greater than the globalSize, resulting in a negative completion percentage. This change makes it so that deleted items are zero bytes large, which makes more sense. Instead we expose the number of files that we need to delete as a separate field in the Completion() result, and hack the percentage down to 95% complete if it was 100% complete but we need to delete files. This latter part is sort of ugly, but necessary to give the user some sort of feedback.
|
@st-review merge |
st-review
pushed a commit
that referenced
this pull request
Sep 2, 2016
… deletes (fixes #3496) We used to consider deleted files & directories 128 bytes large. After the delta indexes change a bug slipped in where deleted files would be weighted according to their old non-deleted size. Both ways are incorrect (but the latest change made it worse), as if there are more files deleted than remaining data in the repo the needSize can be greater than the globalSize, resulting in a negative completion percentage. This change makes it so that deleted items are zero bytes large, which makes more sense. Instead we expose the number of files that we need to delete as a separate field in the Completion() result, and hack the percentage down to 95% complete if it was 100% complete but we need to delete files. This latter part is sort of ugly, but necessary to give the user some sort of feedback. GitHub-Pull-Request: #3556
st-review
added
the
frozen-due-to-age
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
We used to consider deleted files & directories 128 bytes large. After the delta indexes change a bug slipped in where deleted files would be weighted according to their old non-deleted size. Both ways are incorrect (but the latest change made it worse), as if there are more files deleted than remaining data in the repo the needSize can be greater than the globalSize, resulting in a negative completion percentage.
This change makes it so that deleted items are zero bytes large, which makes more sense. Instead we expose the number of files that we need to delete as a separate field in the Completion() result, and hack the percentage down to 95% complete if it was 100% complete but we need to delete files. This latter part is sort of ugly, but necessary to give the user some sort of feedback.
Also, we must make sure to use the
(*FileInfo).FileSizemethod to get the size of something when it can be a directory or a deleted item, as theSizefield may be a lie in those cases.Testing
I added a unit test for the calculation, which failed before the fix. I haven't tested the corresponding fixup in the GUI because it's hard...