You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I noticed an interesting new feature was added in a recent PR #229 , but I think there are some areas where the process could be optimized. So I created a process that I think might be better, pls see the image below.
The current process seems to only use the cached remote state file, which behavior ignores changes committed by others during the time you issue them, causing your data to overwrite other people's submitted modifications.
In the modified process, we simultaneously perform diff and get new data again. If the new data is the same as the local one, then we can directly sync the diffed data. If it is different, we can use the newly obtained data to diff again and perform sync, which is consistent with the original logic.
Maybe this logic still has its shortcomings or is a bit too taken for granted. Suggestions and comments are welcome. (For convenience, I leave the address of the above image so that anyone can copy and edit it)
If I had the time and energy, I would help to realize this logic. 😺
The text was updated successfully, but these errors were encountered:
Description
Hi, I noticed an interesting new feature was added in a recent PR #229 , but I think there are some areas where the process could be optimized. So I created a process that I think might be better, pls see the image below.
The current process seems to only use the cached remote state file, which behavior ignores changes committed by others during the time you issue them, causing your data to overwrite other people's submitted modifications.
In the modified process, we simultaneously perform diff and get new data again. If the new data is the same as the local one, then we can directly sync the diffed data. If it is different, we can use the newly obtained data to diff again and perform sync, which is consistent with the original logic.
Maybe this logic still has its shortcomings or is a bit too taken for granted. Suggestions and comments are welcome. (For convenience, I leave the address of the above image so that anyone can copy and edit it)
If I had the time and energy, I would help to realize this logic. 😺
The text was updated successfully, but these errors were encountered: