TL;DR Useful Tips All-In-One Index

There are lots of useful information about review board out there but sometimes it’s hard and costly to dig for them. Wouldn’t it be nice if there’s an index for them to save all the random access cost to search for them?

Well, here it is. If we all contribute to this list with tips or links to useful information, then this can be very useful for newcomers to review board and a great ‘how-do-I-do-that-again’ reference for everyone.

Getting Started on Review Board

  • Apply a patch the git way
  • 1. download the diff (from a review request etc)
    2. put it in the rb repo, then:
    3. $ git apply rb****.patch
  • Apply a patch the cool johns187 way
  • $ rb patch <rid>

Testing Review Board

  • To test review board in local test environment
Add new repository on localhost:
name: Review Board
hosting service: GitHub
project owner: reviewboard
project name: reviewboard

post-review --server=http://localhost:8080

Link to post:

  • To run a specific unit test case (subset of test cases):
./reviewboard/ test -- reviewboard.scmtools.tests:GitTests.testFilemodeWithFollowingDiff

Link to post:

CSS tips

  • Use the 4 CSS rules of multiplicity well
1. Multiple declarations can live in a single rule.
2. Multiple selectors can preface the same rule set.
3. Multiple rules can be applied to the same selector.
4. Multiple classes can be set on a single element.

Link to external post:

  • Good practice: Use the multiplicity rules instead of mixins (less css)
  • "Mixins are neat and all, but my preference is to avoid them in cases like this (when you want two classes of basically the same thing but only a slight difference, such as one floats left and one floats right). The code should be:
    .class1, .class2 {
       // All the common stuff here.
    And then have the .class1 and .class2 rules define their own specific stuff (like their own floats and 'a' rules).
    The reason is that, while it's neat to be able to include data like this in lesscss, in the end it's really just turning into even more CSS code the browser has to load in and keep separate, and it's more work to debug. It's equivalent to copy/paste.
    Similarly, this situation (class inheritance) shouldn't use a mixin, as it brings in a lot of code. Instead, the elements using the various "child" classes should be also specifying "parent" as a class. More reuse, less debugging and less output."
                                                                      - ChipX86

We are using LESS for reviewboard, more about LESS:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s