Mercurial > mplayer.hg

changeset 18841:3f59edf39ea2

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
cosmetics
author diego
date Wed, 28 Jun 2006 17:03:16 +0000
parents 3b42c599ea09
children 518282cbf238
files DOCS/tech/svn-howto.txt
diffstat 1 files changed, 30 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/DOCS/tech/svn-howto.txt	Wed Jun 28 17:02:56 2006 +0000
+++ b/DOCS/tech/svn-howto.txt	Wed Jun 28 17:03:16 2006 +0000
@@ -30,6 +30,7 @@
 MPlayer project you are expected to be familiar with these rules.
 
 
+
 I. BASICS:
 ==========
 
@@ -39,12 +40,14 @@
 
   This will put the MPlayer sources into the directory <target>.
 
+
 2. Updating the source tree to the latest revision:
 
     svn update
 
   pulls in the latest changes from the repository to your working directory.
 
+
 3. Adding/removing files/directories:
 
     svn add <filename/dirname>
@@ -53,12 +56,14 @@
   Subversion needs to get notified of all changes you make to your working
   directory.
 
+
 4. Showing modifications:
 
     svn diff <filename(s)>
 
   will show all local modifications in your working directory as unified diff.
 
+
 5. Inspecting the changelog:
 
     svn log <filename(s)>
@@ -67,6 +72,7 @@
   more comfortable than using 'svn log' and 'svn diff'. Find it here:
   http://svn.mplayerhq.hu/mplayer/trunk/
 
+
 6. Checking source tree status:
 
   svn status
@@ -74,6 +80,7 @@
   detects all the changes you made and lists what actions will be taken in case
   of a commit (additions, modifications, deletions, etc.).
 
+
 7. Committing:
 
     svn update
@@ -113,6 +120,7 @@
   levels look at and educate themselves while reading through your code. Don't
   include filenames in log messages, Subversion provides that information.
 
+
 8. Renaming/moving files or contents of files:
 
   svn move <source> <destination>
@@ -128,6 +136,7 @@
   Such actions are useless and treated as cosmetics in 99% of cases,
   so try to avoid them.
 
+
 9. Reverting broken commits
 
   There is no Subversion equivalent of the 'cvs admin -o' command. Instead,
@@ -136,6 +145,7 @@
   You may want to use 'svn cat -r<revision> <filename>' to inspect an older
   revision.
 
+
 10. Reverting local changes
 
   svn revert <filename(s)>
@@ -146,6 +156,7 @@
   server! It only reverts changes that were not committed yet. If you need
   to revert a broken commit, see 9.
 
+
 11. Changing commit messages
 
   svn propedit svn:log --revprop -r <revision>
@@ -153,6 +164,7 @@
   If your commit message is too short or not explanatory enough, you can edit
   it afterwards with svn' propedit'.
 
+
 Contact the project admins <root at mplayerhq dot hu> if you have technical
 problems with the Subversion server.
 
@@ -167,18 +179,22 @@
    (#ifdef etc) by default so it does not interfere with other developers'
    work.
 
+
 2. You don't have to over-test things. If it works for you, and you think it
    should work for others, too, then commit. If your code has problems
    (portability, exploits compiler bugs, unusual environment etc) they will be
    reported and eventually fixed.
 
+
 3. Do not commit unrelated changes together, split them into self-contained
    pieces.
 
+
 4. Do not change behavior of the program (renaming options etc) or
    remove functionality from the code without approval in a discussion on
    the mplayer-dev-eng mailing list.
 
+
 5. Do not commit changes to the build system (Makefiles, configure script)
    which change behaviour, defaults etc, without asking first. The same
    applies to compiler warning fixes, trivial looking fixes and to code
@@ -187,6 +203,7 @@
    list, and if the code maintainers say OK, you may commit. This does not
    apply to files you wrote and/or maintain.
 
+
 6. We refuse source indentation and other cosmetic changes if they are mixed
    with functional changes, such commits will be rejected and removed. Every
    developer has his own indentation style, you should not change it. Of course
@@ -198,10 +215,12 @@
    NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code,
    do NOT change the indentation of the inner part (don't move it to the right)!
 
+
 7. Always fill out the commit log message. Describe in a few lines what you
    changed and why. You can refer to mailing list postings if you fix a
    particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
 
+
 8. If you apply a patch by someone else, include the name and email address in
    the log message. Since the mplayer-cvslog mailing list is publicly
    archived you should add some spam protection to the email address. Send an
@@ -209,18 +228,22 @@
    you applied the patch. If the patch contains a documentation change, commit
    that as well; do not leave it to the documentation maintainers.
 
+
 9. Do NOT commit to code actively maintained by others without permission. Send
    a patch to mplayer-dev-eng instead.
 
+
 10. Subscribe to the mplayer-cvslog mailing list. The diffs of all commits
     are sent there and reviewed by all the other developers. Bugs and possible
     improvements or general questions regarding commits are discussed there. We
     expect you to react if problems with your code are uncovered.
 
+
 11. Update the documentation if you change behavior or add features. If you are
     unsure how best to do this, send a patch to mplayer-docs, the documentation
     maintainers will review and commit your stuff.
 
+
 Also read DOCS/tech/patches.txt !!!!
 
 We think our rules are not too hard. If you have comments, contact us.
@@ -236,8 +259,10 @@
 
     svn checkout svn://svn.mplayerhq.hu/mplayer/trunk/ devel
 
+
 2. Make your changes.
 
+
 3. Create a patch:
 
   Run 'svn diff' from the root of the source tree, like this:
@@ -250,6 +275,7 @@
 
     svn diff mplayer.c > ../major_cleanup.patch
 
+
 4. Check the patch:
 
   Check out another, clean source tree and verify your patch:
@@ -267,16 +293,19 @@
   section II, specifically rules 1 to 6, before you continue submitting
   the patch.
 
+
 5. Submit the patch:
 
   Send an e-mail to the mplayer-dev-eng mailing list. Describe what your
   patch does and why, and attach the patch file for review by others.
 
+
 6. During the review process, incorporate all suggested fixes. Go to step 2
   repeatedly until there is nothing more to do for step 6. Of course, if
   you don't agree with certain suggestions, things can be discussed on
   the mailing list in a polite manner.
 
+
 7. Commit the patch:
 
   If your patch is accepted, double check if your source tree contains the
@@ -287,6 +316,7 @@
 
   Go to step 2 ad infinitum until MPlayer is the perfect media player ;)
 
+
 Note: If you are listed as the maintainer for a particular piece of code,
 you can skip step 5 and 6 if your patch _only_ applies to the code you
 maintain. If it touches other code or is otherwise very intrusive, please