Repository navigation
feat: add support for path conflicts with 'prefer' - #201
Conversation
The "prefer" keyword is used to resolve path conflicts according to the RK021 path conflicts spec.
| paths := make(map[string]*Slice) | ||
| for _, new := range selection.Slices { | ||
| for newPath, newInfo := range new.Contents { | ||
| if old, ok := paths[newPath]; ok { |
There was a problem hiding this comment.
[Comment for reviewer]: This logic was not used anymore and was duplicating the conflict detection by doing it once when parsing the release and another time when getting the selection.
| // having to do further processing. | ||
| nodes := make(map[string]*Slice) | ||
| successors := make(map[string][]string) | ||
| const ( |
There was a problem hiding this comment.
[Comment for reviewer]: I thought about moving this state machine checks to the Tarjan Sort. However, I don't really see a benefit in doing that. It means that Tarjan Sort will need to keep track of whether paths are disconnected or have prefers (node can appear in any order if there are no edges). Additionally, it will be difficult to not deviate from the previous algorithm that was checking for SameContent inline. For example, how would we know if a node without prefers need to be checked because it is disconnected, or not because it is the tail of a prefers. Without the state machine, that is very hard to do.
|
701ea5e to
c634f95
Compare
c634f95 to
11c8f61
Compare
niemeyer
left a comment
niemeyer
left a comment
There was a problem hiding this comment.
Thanks for curating this for integration, Alberto.
Only a couple of trivials.
The "prefer" keyword is used to resolve path conflicts according to the RK021 path conflicts spec.