EngineeringProductivity/Projects/MozReview: Difference between revisions

EngineeringProductivity/Projects/MozReview (view source)

Revision as of 01:34, 24 July 2014

59 bytes added , 24 July 2014

→‎The new: branches

Gszorc

canmove, Confirmed users

409

edits

@@ Line 16: / Line 16: @@
 versions of the attached patch file and allows you to add comments to the diff.  While tools such as [http://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hgext/bzexport bzexport] have improved usability, Splinter is fundamentally limited.  Adding useful features like increased context (outside of the patch itself), history, interdiffs, and so on are possible to varying degrees, all are made difficult or largely impossible by the fact that Splinter is based on patches.
-== The new: branches ==
+== The new: repository-centric development ==
-GitHub really popularized the idea of doing branch-based code
+GitHub really popularized the idea of doing repository-centric code review via Git's branches and GitHub's pull requests feature. Essentially, you clone a repository, create a branch, push that branch to a remote, and trigger a code review from that pushed branch.
-reviews.  You have a forked repo of a project (which I am told is,
-under the covers, actually branches, not a separate repo), you push
-changes to your repo, and then you issue a Pull Request, which is
-essentially a way for the author of the main fork to review your
-changes and then easily merge them in.
-Setting aside the last part--which we'll get to later--the advantages
+This approach puts the code repository and version control system front-and-center. Contrast with exchanging patches, which are representations of changes.
-of this code-review system are several, notably
-* You can get full context of the changes.
+There are several advantages to a repository-centric approach to code review:
-* You can address review points by pushing a new commit, which inherently allows interdiffing.
-* You can easily pull down the branch under review for testing.
-Several other tools, such as [https://code.google.com/p/gerrit/ Gerrit],
+* You can get full context of the changes from the underlying repo
-implement this functionality as well, but sadly none of the good
+* You can address review points by pushing a new commit, which inherently allows interdiffing
-options support multiple VCSes, and Mozilla still uses mercurial
+* You can easily pull down the branch under review for testing
-heavily.
+Several other tools, such as [https://code.google.com/p/gerrit/ Gerrit], implement this functionality as well, but sadly none of the good options support multiple VCSes, and Mozilla still uses Mercurial heavily.
 = The Solution: Review Board and friends =