# HG changeset patch
# User diego
# Date 1172595996 0
# Node ID a50a835635c76732f6b094f89f4d4f2d71442b04
# Parent  31baf435c22980616a3ea7ec4800ff8b5d27bf72
grammar/spelling

diff -r 31baf435c229 -r a50a835635c7 DOCS/tech/svn-howto.txt
--- a/DOCS/tech/svn-howto.txt	Tue Feb 27 17:06:04 2007 +0000
+++ b/DOCS/tech/svn-howto.txt	Tue Feb 27 17:06:36 2007 +0000
@@ -179,7 +179,7 @@
   part of the directly visible history of the revisions after the reversal
   So if the change was completely broken like reindenting a file against the
   maintainers decision, or a change which mixed functional and cosmetic
-  changes then its better if its not part of the visible history as it
+  changes then it is better if it is not part of the visible history as it
   would make it hard to read, review and would also break svn annotate
   For the example of a change which mixed functional and cosmetic parts they
   should of course be committed again after the reversal but separately, so one
@@ -188,12 +188,12 @@
   totally broken then it should be reversed with svn merge as otherwise
   the fact that the change was bad would be hidden
   One method to decide which reversal method is best is to ask yourself
-  if theres any value in seeing the whole bad change and its removal
-  in svn vs. just seeing a comment that says what has been reversed while
+  if there is any value in seeing the whole bad change and its removal
+  in SVN vs just seeing a comment that says what has been reversed while
   the actual change does not clutter the immediately visible history and
   svn annotate.
   If you are even just slightly uncertain how to revert something then ask on
-  the mplayer-dev mailinglist.
+  the mplayer-dev-eng mailing list.
 
 
 10. Reverting local changes