mirror of
https://github.com/mpv-player/mpv
synced 2024-12-15 03:15:52 +00:00
cba56d7ff4
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18831 b3059339-0415-0410-9bf9-f77b7e298cf2
204 lines
7.5 KiB
Plaintext
204 lines
7.5 KiB
Plaintext
|
|
About Subversion write access:
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Before everything else, you should know how to use Subversion properly.
|
|
Subversion comes with some documentation.
|
|
|
|
svn help
|
|
man svn
|
|
info svn
|
|
|
|
are a good start. The most comprehensive manual is the book "Version Control
|
|
with Subversion" by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael
|
|
Pilato. It can be viewed online at
|
|
|
|
http://svnbook.org/
|
|
|
|
For more information about the Subversion project, visit
|
|
|
|
http://subversion.tigris.org/
|
|
|
|
Consult these resources whenever you have problems, they are quite exhaustive.
|
|
What follows now are MPlayer specific guidelines.
|
|
|
|
|
|
I. TECH SIDE:
|
|
=============
|
|
|
|
1. Checking out development source tree:
|
|
|
|
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk/
|
|
|
|
2. Updating source tree to latest revision:
|
|
|
|
svn update
|
|
|
|
3. Committing changes:
|
|
|
|
svn update
|
|
svn commit --username USERNAME filename(s)
|
|
|
|
Do not use comments such as: "bug fix." or "files changed" or "dunno".
|
|
You don't have to include the filename in the comment, as comments are linked
|
|
to files. If you have made several independent changes, commit them
|
|
separately, not at the same time. You will be prompted for a comment in an
|
|
editor, which is either specified by --editor-cmd on the command line, set
|
|
in your personal configuration file (~/.subversion/config) or set by one of
|
|
the following environment variables: SVN_EDITOR, VISUAL or EDITOR. When
|
|
prompted for a password, type the password you got assigned by the Subversion
|
|
server admin. By default, Subversion caches all authentication tokens. This
|
|
behaviour can be disabled by setting both 'store-passwords' and
|
|
'store-auth-creds' to "no" in ~/.subversion/config. You might need to remove
|
|
previous cache files, which are located in ~/.subversion/auth, by hand.
|
|
|
|
4. Adding new files/directories:
|
|
|
|
svn add filename/dirname
|
|
svn commit filename/dirname
|
|
|
|
5. Removing files:
|
|
|
|
svn delete filename
|
|
svn commit filename
|
|
|
|
6. Checking changes:
|
|
|
|
svn diff filename(s)
|
|
|
|
Doublecheck your changes before committing to avoid trouble later on.
|
|
This way you will see if your patch has debug stuff or indentation
|
|
changes and you can fix it before committing and triggering flames.
|
|
|
|
7. Checking changelog:
|
|
|
|
svn log filename(s)
|
|
|
|
You may also find viewvc, a web frontend for Subversion, helpful. It's often
|
|
more comfortable than using svn log and svn diff. Find it here:
|
|
http://svn.mplayerhq.hu/mplayer/trunk/
|
|
|
|
8. Renaming/moving files or content of files:
|
|
|
|
svn move source destination
|
|
svn commit source destination
|
|
|
|
Do not move or rename files before discussing it on the mplayer-dev-eng
|
|
mailing list first!
|
|
|
|
Don't do a lot of cut'n'paste from one file to another without a very good
|
|
reason and discuss it on the mplayer-dev-eng mailing list first. It will make
|
|
those changes untraceable!
|
|
|
|
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,
|
|
be very careful about what you commit! If somehow you broke something,
|
|
revert the changes locally and re-commit with a proper commit message.
|
|
You may want to use 'svn cat -r<revision> filename' to inspect an older
|
|
revision.
|
|
|
|
10. Checking status of source tree
|
|
|
|
svn status
|
|
|
|
This will detect all the changes you made and list what actions will be
|
|
taken in case of a commit (Additions, Modifications, Deletions, et cetera).
|
|
|
|
11. Reverting local changes
|
|
|
|
svn revert filename(s)
|
|
|
|
In case you made a lot of local changes to a file and want to start over
|
|
with a fresh checkout of that file, you can use svn revert filename(s).
|
|
NOTE: This has nothing to do with reverting changes on the Subversion
|
|
server! It only reverts changes that were not committed yet. If you need
|
|
to revert a broken commit, see 9.
|
|
|
|
12. Changing commit messages
|
|
|
|
svn propedit svn:log --revprop -r <revision>
|
|
|
|
If your commit message is too short or not explanatory enough, you can edit
|
|
it afterwards with svn propedit.
|
|
|
|
Contact the project admin <root at mplayerhq dot hu> if you have technical
|
|
problems with the Subversion server.
|
|
|
|
|
|
|
|
II. POLICY / RULES:
|
|
===================
|
|
|
|
1. You must not commit code which breaks MPlayer! (Meaning unfinished but
|
|
enabled code which breaks compilation or compiles but does not work.)
|
|
You can commit unfinished stuff (for testing etc), but it must be disabled
|
|
(#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
|
|
maintained by other developers. We usually have a reason for doing things
|
|
the way we do. Send your changes as patches to the mplayer-dev-eng mailing
|
|
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
|
|
if you (re)write something, you can use your own style... (Many projects
|
|
force a given indentation style - we don't.) If you really need to make
|
|
indentation changes (try to avoid this), separate them strictly from real
|
|
changes.
|
|
|
|
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
|
|
answer to mplayer-dev-eng (or wherever you got the patch from) saying that
|
|
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.
|
|
|
|
|
|
|
|
III. Beginners Guide
|
|
====================
|