Add support for posting changes to Cliosoft SOS repositories.
Review Request #12237 — Created April 18, 2022 and submitted
Cliosoft SOS (https://www.cliosoft.com/products/sos/) is an
enterprise-grade source code management solution used throughout the
hardware industry. Its features are tailored to large, distributed teams
working with inter-dependent projects. It supports large files,
"packages" of related files that must be managed under a single
revision, general attribute metadata support, file locking, ACLs, sparse
checkouts, snapshots, and other feaures useful in enterprise settings.
Through a combination of RBTools 3.1+, Review Board 4.0.6+, Power Pack
5+, and SOS 7.20+, users will be able to configure Review Board to talk
to Cliosoft SOS repositories and post changes for review.
Users can post explicit selections for review, such as:
$ rbt post select:-scm $ rbt post 'select:-sunm -sor -scm'
Or they can post SOS changelists (new in 7.20) by name:
$ rbt post my-changelist-name
The generated diff uses the DiffX (https://diffx.org) format, with
metadata specific to SOS. This is used to identify the workarea, SOS
Project, SOS Server, changelist ID, and RSO (Revision Search Order) that
Some of this information is also returned during diff generation for
storage in the review request. This enables custom SOS fields in the
review request to show up, which will contain information useful to
reviewers and the owner to help determine which workarea and changelist
contains the changes.
That logic (along with
get_tree_matches_review_request()) will also
enable smart matching of review requests for
rbt post -u, which is
another change in development.
At the moment, this does not support posting files bundled as SOS
packages for review. That is planned for a subsequent release.
SOS 7.20 is required for this release, though the code has been written
to not strictly enforce this version yet, as some customers are using
patched builds of earlier releases that contain this support. In time,
we'll want to make 7.20 a hard requirement.
This work is a collaboration between Beanbag and Cliosoft. A big thanks
to them for all the testing, support, and all the new functionality
added to SOS 7.20 to make this integration happen.
All unit tests pass.
Extensively tested with a variety of types of changes in local SOS
workareas. This included:
- Selection-based posting (default and custom selections)
- Changeset-based posting
- Included files and excluded patterns
- Changed, added, and deleted files (referenced in selections and changesets)
- Symlink changes (though this support still requires further work, and based
on discussions with Cliosoft will be moved to a future release)
- Verification that existing SOS selections are preserved after the
- Tested posting with
rbt post -u(when combined with in-progress changes
for smarter matching)
So right now we're only using one
SOSChangeSetper invocation, but if for some reason someone were to use this multiple times, they'd all share the same instances for
modificationssince these are created at function definition time. It's uglier, but this should probably be changed to default to
Noneand then create the set instances inside the
Is this new?
This is called from numerous places. Can we use
self._workareainstead of those calls, or make this cache it internally?
Nonedefaults instead of
set()to avoid shared state.
SCMClient._workareain favor of the caching in
_get_wa_root()calls, to avoid function call order assumptions.
Revision 2 (+10650 -2)
Checks run (2 succeeded)
Based on a discussion with Cliosoft on final terminology, all references to "changeset" has been replaced with "changelist", including in diff metadata.
Revision 3 (+10650 -2)
Checks run (2 succeeded)