https://s3-us-west-2.amazonaws.com/secure.notion-static.com/b51eb3b5-af60-4084-8f00-024e80de1442/8Fwqijk8TO2qrdDwr1u4_Untitled
contrib/
Tools for contributing to Review Board development. This includes the devserver script (which you'll use all the time), the prepare-dev script (which you'll use some of the time), and several other scripts (which you'll likely never use).
docs/
All Review Board documentation (yes, the documentation that gets put up on reviewboard.org) is hosted here. We use Sphinx to generate documentation, and some of it gets sucked right out from the source code documentation. If you go to docs/manual, and type make html, it will generate the documentation for you locally for you to inspect.
reviewboard/
accounts/
Anything to do with user accounts go here. The Profile model is stored here, which holds things like user preferences. Review request visits are also modeled here, as well as Trophies.
admin/
Django provides an administrative interface for all of the models/configuration of a Django site. We do a bunch of extending/modification of that default administrative interface here.
attachments/
File attachments for a review request include things like images, or other types of binary files. All of that stuff is handled under here.
changedescs/
Every time you publish a change to a review request, we create a "change description" to describe how your review request changed. This is where we model the change descriptions.
cmdline/
rbsite is used in production instances of Review Board for maintenance/upgrades. The rbssh script is a reimplementation of ssh using paramiko. If you have an svn+ssh, or git+ssh connection, you want to use rbssh. As a student developer, you probably won't need to mess with anything in here unless you're fixing bugs on them.
datagrids/
Datagrids are what we use to show lists of things like review requests, reviews, user accounts, etc. A datagrid looks like this:
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/27f7dbd3-0e8f-4860-af51-b4f77e4f7f77/X65Y9gUFTOGqT9gOnCAC_Untitled
Datagrids are a feature that Djblets offers, and the datagrids folder under reviewboard/ is where we define the Review Board-specific datagrids.
diffviewer/
The side-by-side diffviewer for Review Board, along with the logic for producing the diffs, is all handled here.
extensions/
Review Board-specific extension hooks are defined here — so like, the hooks and template tags for putting in buttons in the review_details header.
hostingsvcs/
Review Board can talk to services that host repositories, or issues. Examples of these services include: GitHub, Beanstalk, GitLab, Google Code, etc. This folder contains the generic HostingService class, and the specific implementations for each service that Review Board can talk to.
htdocs/
Special site-wide static HTML files, like the 500 error page, is here. You'll also find the compiled versions of JavaScript and CSS here—note that if you change them, they'll get overwritten. Only change JS/CSS in static/
locale/
Review Board can be localized! Translations for the locales that Review Board supports are here.
notifications/
This is where we put handlers for global signals that Review Board fires. Things like our web hooks implementation live here, as well as the code for sending emails when review requests get created or updated, or when somebody reviews some code.
reviews/
This... this is a major directory.
This is where things like the ReviewRequest model and Review model are defined, which are (obviously) core to what Review Board does. We don't have a single [models.py](<http://models.py>) here, but a models folder with individual models split out into their own files. The backend support for the built-in Review UI's (specialized UI's for reviewing specific file types) is also implemented here.
scmtools/
Review Board is able to communicate with many different repository types out of the box (at this time: Bazaar, ClearCase, CVS, Git, Mercurial, Monotone, Perforce and Plastic). This is where the generic SCMTool class is defined, and the specialized implementations for each repository type.
site/
Review Board makes it possible to run partitioned "sites" of Review Board off of a single instance. RBCommons, for example, does this. This means all of these separate sites share the same repository and Review Board back-end. An instance of a site is called a LocalSite.
ssh/
Sometimes, Review Board communicates with various services using SSH. SSH communication involves storing and retrieving user and host keys. This is the code for that stuff.
static/
All of the static client-side stuff, like CSS and Javascript, goes here. All of our Backbone-y things are here. It gets pretty abstract — take notes.
templates/
When Django returns responses via its views, it usually returns full blown HTML that is defined inside templates in here. The templates for each app goes into a specific folder under here. These use the Django templating language.
testing/
Testing utilities, and the base class for our Django-level testing infrastructure is here.
webapi/
This is another major directory. All of Review Board's WebAPI is defined here. You'll want to check out the resources defined under the resources directory. If all of this WebAPIResource magic is bumming you out, take heart — there's wicked-comprehensive documentation in djblets/djblets/webapi/resources.py.
contrib/
Like the Review Board equivalent, contains handy scripts for hacking on djblets. Unlike the scripts in Review Board, you will seldom, if ever, need to run any of these.
djblets/
auth/
Djblets adds some magic around user registration. Here is that magic.
avatars/
Pluggable avatar backends to make use of gravatar, user-uploaded avatars, or other third-party services.
cache/
Djblets allows a Django application to cache/memorize various things, and store the cache in a variety of backends.
conditions/
This contains a framework for making complicated condition matches, for things like integrations.
configforms/
Common code for configuration forms.
datagrid/
Customizable datagrids that represent paginated lists of database objects. Users can customize the list of columns they list, reorder them, and sort them. Datagrids take care of all the hard work behind the scenes.
db/
Specialized DB fields like JSON and counters.
extensions/
A framework for making a Django app support extensions. This does all of the magic of side-loading an extension as a Django app into an already-running Django application. Extension detection, management, and the base, generic hooks are all implemented here.