[docs] Minor updates to DeveloperPolicy due to svn to git

[jsji]

Summary

This was found accidentaly when sharing policy to new members.

[merge_guards_bot]

Unit tests: pass. 62450 tests passed, 0 failed and 845 were skipped.

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

[jsji]

Ping...

[lebedev.ri]

SGTM

[jsji]

Thanks @lebedev.ri. Would you mind accept it? then I will commit it.

[efriedma]

LGTM

llvm/docs/DeveloperPolicy.rst

* Ask for help on IRC. Developers on IRC will be able to either help you
   directly, or tell you who might be a good reviewer.
 * Split your patch into multiple smaller patches that build on each other. The
   smaller your patch, the higher the probability that somebody will take a quick
   look at it.
 
 Developers should participate in code reviews as both reviewers and
 reviewees. If someone is kind enough to review your code, you should return the
 favor for someone else.  Note that anyone is welcome to review and give feedback
-on a patch, but only people with Subversion write access can approve it.
+on a patch, but only people with GitHub commit access can approve it.
 
 There is a web based code review tool that can optionally be used
 for code reviews. See :doc:`Phabricator`.
 
 .. _code owners:
 
 Code Owners
 -----------
* The body should be concise, but explanatory, including a complete
   review or the mailing list.
 
 * If the patch fixes a bug in bugzilla, please include the PR# in the message.
 
 * Text formatting and spelling should follow the same rules as documentation
   and in-code comments, ex. capitalization, full stop, etc.
 
 * If the commit is a bug fix on top of another recently committed patch, or a
-  revert or reapply of a patch, include the svn revision number of the prior
-  related commit. This could be as simple as "Revert rNNNN because it caused
-  PR#".
+  revert or reapply of a patch, include the git commit hash of the prior
+  related commit. This could be as simple as "Revert commit NNNN because it
+  caused PR#".
 
 For minor violations of these recommendations, the community normally favors
 reminding the contributor of this policy over reverting. Minor corrections and
 omissions can be handled by sending a reply to the commits mailing list.
 
 Obtaining Commit Access
 -----------------------