Add option in ProxiedDevice to only transfer the delta when deploying.#97462
Add option in ProxiedDevice to only transfer the delta when deploying.#97462fluttergithubbot merged 3 commits intoflutter:masterfrom
Conversation
|
Friendly ping on this, PTAL, thanks :) |
There was a problem hiding this comment.
what's the difference here?
There was a problem hiding this comment.
I've changed it to use the same temp directory every time the app runs, so that we could reuse the file that is transferred from the previous run.
There was a problem hiding this comment.
ahh, makes sense.
There was a problem hiding this comment.
could you leave a breadcrumb comment, lest someone revert this in a "cleanup"?
There was a problem hiding this comment.
Good point about leaving a comment, just added. Thanks!
There was a problem hiding this comment.
should we put a debug log if _deltaFileTransfer == true && rollingHashResultJson == null?
There was a problem hiding this comment.
This is normal when it's the first run. But it's probably still a good idea to add a log, just added, thanks!
There was a problem hiding this comment.
oh good point about first run.
There was a problem hiding this comment.
Also, the reason I'm not using
rsyncdirectly is to not introduce any external dependencies, or in case we need to do this on a Windows machine.
Can we rsync when it is available, and fall back to this when it's not? The tool already uses it in a few places.
This is a good suggestion (we might as well use |
|
Sorry for the late reply, missed the email from two weeks ago :( Currently Remote rsync requires different setup. We need to make sure that rsync is available on both ends and that they are compatible (rsync protocol is at version 31 now), and then (without assuming that there is SSH connection available between both ends) start an "rsync daemon" on one machine, forward the port and start an "rsync client" on the other end. I'm mostly worried about the possible edge cases that we'll need to cover, and the security implications of doing this. IMO if we already have to implement the algorithm in the flutter_tools, it is better to use it for all platforms to increase the chance of it being used, therefore higher chance that any bug will be found and fixed. What do you think? |
Ahh, good point. Makes sense to me. |
|
Jenn, what do you think @jmagman ? |
Whatever you and @christopherfujino think to do here |
This PR LGTM as is; however merging is blocked by your requested changes @jmagman |
jmagman
left a comment
There was a problem hiding this comment.
Jenn, what do you think @jmagman ?
Whatever you and @christopherfujino think to do here
rsyncor not works for me. slightly_smiling_faceThis PR LGTM as is; however merging is blocked by your requested changes @jmagman
Ah, sorry, missed that.
Using an rsync-like algorithm. This reduces the data that needs to be transferred, and removes the need to retransfer the assets on subsequent calls on flutter start.
|
Thanks! |
...using an rsync-like algorithm. This reduces the data that needs to be
transferred, and removes the need to retransfer the assets on subsequent
calls on flutter start.
Also, the reason I'm not using
rsyncdirectly is to not introduce any external dependencies, or in case we need to do this on a Windows machine.Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.