fix finding local-versions when on a lane #6519
Merged
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Until now, it was done by traversing the local and remote snaps. The “remote-head” was the head on the remote-lane, and if not-exist (the component is new on this lane), it’s the remote-head of main.
The issue with this is that sometimes we get incorrect results. In case of merging lane-a into lane-b, and a new component introduced as part of the merge to lane-b, all the history of this component of lane-a is considered local. Because this history is considered local, bit-reset removes it unexpectedly.
Another issue is the export performance. We send way too many objects unnecessarily. Especially when lane-a is merged into lane-b, both on the same scope and lane-a has tons of snaps that were already exported.
This PR fixes it by searching all remote-refs files (of lanes only, not main) for a component and during the local history traversal, if a hash is found there, it'll stop the traversal and not mark it as local.
For export, if exporting a lane to a new scope, then, we need all history from original component-scope. however, the history might already been there from previous snaps. to check this, we find all remote-refs of the same scope as the current lane and search for the hashes to stop the traversal.