Author: diego Date: Wed Jun 28 19:03:16 2006 New Revision: 18845 Modified: trunk/DOCS/tech/svn-howto.txt Log: cosmetics Modified: trunk/DOCS/tech/svn-howto.txt ============================================================================== --- trunk/DOCS/tech/svn-howto.txt (original) +++ trunk/DOCS/tech/svn-howto.txt Wed Jun 28 19:03:16 2006 @@ -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