opam update: Avoid reloading repository contents when the repo has not changed#5043
opam update: Avoid reloading repository contents when the repo has not changed#5043rjbou merged 4 commits intoocaml:masterfrom
Conversation
src/state/opamUpdate.ml
Outdated
| job { r with repo_url = new_url } (n-1) | ||
| in | ||
| job repo max_loop @@+ fun repo -> | ||
| job repo max_loop @@+ fun has_changes -> |
There was a problem hiding this comment.
| job repo max_loop @@+ fun has_changes -> | |
| job repo max_loop @@+ fun repo, has_changes -> |
repo is not return by the job function anymore. I belive this would break repositories with redirections from a glance at the code. Could you either return repo as before in a tuple or inside the new [no_changes | changes] state (whichever you think is better)
There was a problem hiding this comment.
you are right of course! I had missed the fact that the repo is returned by job to account for redirections. should be fixed now.
6407321 to
9604c13
Compare
|
note for opam devs: this is going to conflict with #5015 and I think #5015 should be prioritized. I’ll handle rebase of this PR after the merge. @Armael once #5015 is merged I think a simple test could also be added to |
9604c13 to
355bbd7
Compare
|
I have rebased the PR now that #5015 has been merged. I can try to add a test, but I'm not exactly sure how to test the PR, maybe by testing that .tar has not been regenerated by checking the modification date after doing a second |
|
For the test, you can check also check |
355bbd7 to
1c31257
Compare
|
The tests failed with: |
73eb1fc to
530b9fd
Compare
|
Thanks a lot! |
Currently,
opam updatewill reload the state of a repository (reading .opam files, etc) even when the repository has not changed (as detected by the backend).This PR is an attempt at optimizing this case: if the backend says that a repository has not changed, avoid reloading its contents, allowing for quicker
opam updates.(a review is particularly welcome as I am not familiar with this part of opam's code; I might have missed some subtleties wrt synchronization of the on-disk view of the repo and the "repo" in-memory data structure...)