| | Our review request matching ("guessing") code has been around for a very
|
| | long time. It worked by comparing the summary and description of pending
|
| | review requests to the local tree, computing a score, and returning
|
| | either an exact match (100% equal) or a fuzzy match. Fuzzy matches would
|
| | be presented to the user so that they could determine which is the
|
| | correct review request to update. |
| |
|
| | This change greatly enhances this logic, deprecating a lot of old code
|
| | in the process. Review requests can now be matched based on the commit
|
| | ID, or based on review request extra_data content (if the SCMClient
|
| | implementation supports it). |
| |
|
| | Matching is done in three stages now: |
| |
|
| | -
Checks for an exact commit ID match. This is considered an exact
match (mostly useful when matching without changing something that
impacts the commit ID -- this could be used in time to ease attaching
files or publishing changes, for example).
|
| | -
Checks each review request using SCMClient -provided logic, using
the new SCMClient.get_tree_matches_review_request() method, which
can check extra_data for any state it wishes to check. This can
return True if there's an exact match, False if a review request
should be outright rejected (skipping any future matching logic), or
None to proceed to fuzzier matching.
|
| | -
Checks the summary and description against the tree, as before. This
can generate an exact match or a list of fuzzy matches.
|
| |
|
| | If there's only one exact match, then it wins. |
| |
|
| | If there's more than one exact match, they're considered high-priority
|
| | fuzzy matches, appended to any other fuzzy matches found. |
| |
|
| | This will give us a lot of options down the road for enhancing
|
| | operations like posting/updating review requests, closing review
|
| | requests, etc. |
| |
|
| | Short-term, SOS is the only tool that utilizes the extra_data
|
| | matching, and will match a review request if the workarea ID and
|
| | changeset ID stored when creating/updating a review request both match
|
| | the local workarea. |
| |
|
| | There are a few deprecations and related changes: |
| |
|
~ | | |
| ~ | |
| | |
| | |
| | |
| |
|
| | Some comments have been added with planned deprecations to make in
|
| | RBTools 4.0. |
| |
|
| | Unit tests were added for non-deprecated functionality. |