• Get Review Board
  • What's New
  • Products
  • Review Board Code review, image review, and document review
  • Documentation
  • Release Notes
  • Power Pack Enterprise integrations, reports, and enhanced document review
  • Try for 60 Days
  • Purchase
  • RBCommons Review Board as a Service, hosted by us
  • Pricing
  • RBTools Command line tools and Python API for Review Board
  • Documentation
  • Release Notes
  • Review Bot Automated code review, connecting tools you already use
  • Documentation
  • Release Notes
  • RB Gateway Manage Git and Mercurial repositories in your network
  • Documentation
  • Release Notes
  • Learn and Explore
  • What is Code Review?
  • Documentation
  • Frequently Asked Questions
  • Support Options
  • Third-Party Integrations
  • Demo
  • Review Board RBTools Power Pack Review Bot Djblets RB Gateway
    1. RBTools dev
    2. Version 5.x
    3. Version 4.x
    4. Version 3.x
    5. Version 2.0
    6. Version 1.0
    7. Version 0.7
    8. Version 0.6
    9. Version 0.5
    10. RBTools Workflows
    11. Using RBTools With Cliosoft SOS
  • Home
  • Installing RBTools
  • rbt Command
  • Configuration
  • Authenticating to Review Board
  • Repository Configuration
  • Per-User Configuration
  • Team Foundation Server Configuration
  • Commands
  • alias
  • api-get
  • attach
  • clear-cache
  • close
  • diff
  • install
  • land
  • list-repo-types
  • login
  • logout
  • patch
  • post
  • publish
  • review
  • setup-completion
  • setup-repo
  • stamp
  • status
  • status-update
  • RBTools Workflows
  • Using RBTools With Cliosoft SOS
  • Using RBTools with Git
  • Using RBTools with HCL VersionVault and IBM ClearCase
  • Using RBTools With Perforce
  • RBTools Python API
  • Overview of the Python API Client
  • Tutorial
  • Resource-Specific Functionality
  • Module and Class References
  • rbtools
  • rbtools.deprecation
  • rbtools.api
  • rbtools.api.cache
  • rbtools.api.capabilities
  • rbtools.api.client
  • rbtools.api.decode
  • rbtools.api.decorators
  • rbtools.api.errors
  • rbtools.api.factory
  • rbtools.api.request
  • rbtools.api.resource
  • rbtools.api.transport
  • rbtools.api.transport.sync
  • rbtools.api.utils
  • rbtools.clients
  • rbtools.clients.base
  • rbtools.clients.base.patch
  • rbtools.clients.base.registry
  • rbtools.clients.base.repository
  • rbtools.clients.base.scmclient
  • rbtools.clients.errors
  • rbtools.clients.bazaar
  • rbtools.clients.clearcase
  • rbtools.clients.cvs
  • rbtools.clients.git
  • rbtools.clients.mercurial
  • rbtools.clients.perforce
  • rbtools.clients.plastic
  • rbtools.clients.sos
  • rbtools.clients.svn
  • rbtools.clients.tfs
  • rbtools.config
  • rbtools.config.config
  • rbtools.config.loader
  • rbtools.diffs
  • rbtools.diffs.patches
  • rbtools.diffs.patcher
  • rbtools.diffs.tools
  • rbtools.diffs.tools.backends
  • rbtools.diffs.tools.backends.gnu
  • rbtools.diffs.tools.base
  • rbtools.diffs.tools.base.diff_file_result
  • rbtools.diffs.tools.base.diff_tool
  • rbtools.diffs.tools.errors
  • rbtools.diffs.tools.registry
  • rbtools.diffs.writers
  • rbtools.commands
  • rbtools.commands.main
  • rbtools.commands
  • rbtools.commands.base
  • rbtools.commands.base.commands
  • rbtools.commands.base.errors
  • rbtools.commands.base.options
  • rbtools.commands.base.output
  • rbtools.commands.alias
  • rbtools.commands.api_get
  • rbtools.commands.attach
  • rbtools.commands.clearcache
  • rbtools.commands.close
  • rbtools.commands.diff
  • rbtools.commands.info
  • rbtools.commands.install
  • rbtools.commands.land
  • rbtools.commands.list_repo_types
  • rbtools.commands.login
  • rbtools.commands.logout
  • rbtools.commands.patch
  • rbtools.commands.post
  • rbtools.commands.publish
  • rbtools.commands.review
  • rbtools.commands.setup_completion
  • rbtools.commands.setup_repo
  • rbtools.commands.stamp
  • rbtools.commands.status
  • rbtools.commands.status_update
  • rbtools.hooks
  • rbtools.hooks.common
  • rbtools.hooks.git
  • rbtools.testing
  • rbtools.testing.api
  • rbtools.testing.api.payloads
  • rbtools.testing.api.transport
  • rbtools.testing.commands
  • rbtools.testing.testcase
  • rbtools.testing.transport
  • rbtools.utils
  • rbtools.utils.aliases
  • rbtools.utils.browser
  • rbtools.utils.checks
  • rbtools.utils.commands
  • rbtools.utils.console
  • rbtools.utils.diffs
  • rbtools.utils.encoding
  • rbtools.utils.errors
  • rbtools.utils.filesystem
  • rbtools.utils.graphs
  • rbtools.utils.mimetypes
  • rbtools.utils.process
  • rbtools.utils.repository
  • rbtools.utils.review_request
  • rbtools.utils.source_tree
  • rbtools.utils.users
  • Glossary
  • General Index
  • Python Module Index
  • Release Notes
  • This documentation covers the in-development release of RBTools. You can see the stable RBTools documentation or all previous versions.

    Using RBTools With Cliosoft SOS¶

    This guide covers how you can use RBTools to post changes to Cliosoft SOS 7.20 or higher. We’ll cover posting both selections and changelists (new in SOS 7.20) for review.

    A typical workflow looks like this:

    1. Create a SOS changelist for your changes (optional)

    2. Post your changes for review (via changelist or selection)

    3. Make changes based on feedback and re-post for review

    4. Commit your change to SOS

    5. Close your review request

    We’ll go over these concepts and then show you an example session.

    Important

    You’ll need to wait to commit your changes until after you’re finished with the review process and your change has been approved (with a Ship It!).

    Changes that are already committed cannot currently be posted for review.

    Step 1. Create a SOS changelist for your changes¶

    SOS changelists are new in SOS 7.20, and are recommended to help you keep track of all the files that you want to post for review and, later, commit to your project.

    Note

    Changelists require a writable workarea (soscmd newworkarea -LWRITABLE ...).

    Changelists are created through socmd add, like so:

    $ soscmd add -c <changelist_name> <file1> <file2> ...
    

    For example:

    $ soscmd add -c memory-leak-fix src/driver-main.c src/memutils.c
    

    You can name the changelist anything you want, and can pass any files you’ve created, modified, or deleted.

    If you choose not to use changelists, then you’ll instead post selections for review, which we’ll show below.

    Step 2: Post your change for review¶

    There are three ways you can post changes for review:

    1. If you have a changelist to post, you can pass the name to post.

      $ rbt post <changelist_name>
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      

      For example:

      $ rbt post memory-leak-fix
      
    2. You can simply post all the files that you’ve modified or added to/deleted from checked-out directories by running:

      $ rbt post
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      

      That’s roughly equivalent to posting a selection represented by the -scm selection flag.

    3. You can post an explicit selection:

      $ rbt post "select:<flags>"
      

      For example:

      $ rbt post "select:-scm -sor -sunm"
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      

    Including/Excluding Files¶

    You can also provide the explicit files you want to post for review with rbt post -I:

    $ rbt post -I <file1> -I <file2>
    

    Or exclude certain file patterns from a changelist or selection with rbt post -X:

    $ rbt post -X '*.txt'
    

    These can be paired with a selection or a changelist name.

    Once you’ve posted…¶

    Your changes are now posted to Review Board, but are in a draft state. Nobody can see it until you’re ready to publish.

    You’ll now need to go to the URL and fill out the Summary, Description, or any other fields.

    If you have default reviewers set up, they’ll be assigned automatically, but you can also specify the people or groups you want to review your change.

    Once you’re done filling out fields on the review request, click Publish to send it out for review.

    Step 3: Update from reviewer feedback and re-post¶

    Got some reviewer feedback to incorporate into your change? Easy.

    1. Make the changes to your tree (make sure not to commit yet!)

    2. If you’re using changelists, run rbt post -u <changelist_name> to update your review request.

      This will try to locate the review request you posted to before, comparing workarea ID and changelist name. It will ask you if it’s not sure which one is correct.

      For example:

      $ rbt post -u memory-leak-fix
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      

      If you’re using selections, you’ll need to instead run rbt post -r <review_request_id> with your preferred selection or -I/-X to update the desired review request.

      For example:

      $ rbt post -r 123
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      

      Or:

      $ rbt post -r 123 "select:-scm -sor -sunm"
      Review request #123 posted.
      
      https://reviewboard.example.com/r/123/
      https://reviewboard.example.com/r/123/diff/
      
    3. Update any information on the review request, if you want to.

      We recommend describing the changes you’ve made, so reviewers know what to look for. The field for this is on the green draft banner.

    4. Publish the new changes for review.

    5. Rinse and repeat until you have the necessary approval to commit your change.

    Step 4: Commit your change¶

    Once you’ve gotten approval to commit the change, you can commit it using soscmd as normal.

    To commit your changelist, use soscmd commit. For example:

    $ soscmd commit -c memory-leak-fix
    

    To commit your selections, use soscmd ci as normal.

    Step 5: Close your review request¶

    Now that your change is in, it’s time to close your review request.

    1. Navigate to the review request and close it.

      In Review Board 6 and newer, click Close -> Completed.

      In Review Board 5 and older, click Close -> Submitted.

    2. Run rbt close <review request ID> (see the documentation).

    Putting it all together¶

    Let’s walk through an example using changelists in a writeable workarea.

    Posting your change¶

    First, assume we’ve created a file (newfile), deleted a file (oldfile), and modified a file (changedfile).

    Let’s create a changelist and add these files to it (note that we can call soscmd add multiple times if we want to):

    $ soscmd add -c my-changelist newfile oldfile changedfile
    

    We now have a changelist called my-changelist. Let’s post it for review.

    $ rbt post my-changelist
    Review request #1001 posted.
    
    https://reviewboard.example.com/r/1001/
    https://reviewboard.example.com/r/1001/diff/
    

    The review request will be posted, and will start off blank. You can go to the URL now to fill out those fields, and then click Publish.

    Wait and grab some coffee…

    Update From review feedback¶

    Hey, we got some review feedback. Let’s make some changes to those files in our changelist and then update our review request:

    $ rbt post -u my-changelist
    Review request #1001 posted.
    
    https://reviewboard.example.com/r/1001/
    https://reviewboard.example.com/r/1001/diff/
    

    Go to the review request, describe what you’ve fixed to help our your fellow reviewers, and publish the new draft.

    Tip

    You can update (-u), describe the changes (-m), and publish (-p), all in the same step:

    $ rbt post -u -m "Fixed a broken link." -p my-changelist
    

    Commit the change¶

    Once you’ve gotten an approval (reviews with a “Ship It!” that match your department/company’s policies), you can commit your change and close the review request.

    $ soscmd commit -c my-changelist
    $ rbt close 1001
    

    (You can also close it in the review request page).

    You’ll get the hang of this process in no time. Soon you’ll be well on your way to better code quality.

    Keep up with the latest Review Board releases, security updates, and helpful information.

    About
    News
    Demo
    RBCommons Hosting
    Integrations
    Happy Users
    Support Options
    Documentation
    FAQ
    User Manual
    RBTools
    Administration Guide
    Power Pack
    Release Notes
    Downloads
    Review Board
    RBTools
    Djblets
    Power Pack
    Package Store
    PGP Signatures
    Contributing
    Bug Tracker
    Submit Patches
    Development Setup
    Wiki
    Follow Us
    Mailing Lists
    Reddit
    Twitter
    Mastodon
    Facebook
    YouTube

    Copyright © 2006-2025 Beanbag, Inc. All rights reserved.

    Terms of Service — Privacy Policy — AI Ethics Policy — Branding

    On this page

    • [Top]
    • Step 1. Create a SOS changelist for your changes
    • Step 2: Post your change for review
      • Including/Excluding Files
      • Once you’ve posted…
    • Step 3: Update from reviewer feedback and re-post
    • Step 4: Commit your change
    • Step 5: Close your review request
    • Putting it all together
      • Posting your change
      • Update From review feedback
      • Commit the change