[MPlayer-cvslog] r18831 - trunk/DOCS/tech/svn-howto.txt
ivo
subversion at mplayerhq.hu
Mon Jun 26 21:03:51 CEST 2006
Author: ivo
Date: Mon Jun 26 21:03:51 2006
New Revision: 18831
Modified:
trunk/DOCS/tech/svn-howto.txt
Log:
Remove old CVS beginners guide
Modified: trunk/DOCS/tech/svn-howto.txt
==============================================================================
--- trunk/DOCS/tech/svn-howto.txt (original)
+++ trunk/DOCS/tech/svn-howto.txt Mon Jun 26 21:03:51 2006
@@ -199,145 +199,5 @@
-III. Beginners Guide by David Holm
+III. Beginners Guide
====================
-
-When I first got CVS write access I got banned after only a few hours
-because I didn't fully understand this documentation. This part is for
-those of you who have just got CVS write access and want to avoid the
-most common pitfalls leading to CVS ban.
-I will introduce a step-by-step guide explaining how I'm making sure
-that my CVS commits are proper and won't get me banned.
-
-1. You should set up two directoress for MPlayer, one which contains the stable
- version and has the :ext: option instead of :pserver: in CVS/Root.
- The other should be your development directory and have the CVS/Root set to
- :pserver: instead of :ext:, that way you can't commit development code
- by accident (since only :ext: allows writes).
- This is my setup:
- ~/mplayer
- /main
- /main.dev
- NOTE: I'll use these directory names from here on in the guide, what you
- call your directories is entirely up to you. This is _only_ an example.
-
-2. When you are satisfied with the changes in "main.dev" and think you are
- ready to commit the changes to CVS start by doing the following in the
- "~/mplayer" dir":
- diff -Nur -x "CVS" -x ".*" main main.dev > dev2stable
- dev2stable is the filename for the patchfile, it doesn't matter what you
- call it.
-
-3. Now comes one of the tricky parts, editing the patch. I prefer using mcedit
- (comes with Midnight Commander) since it does syntax highlighting in patches
- (= it uses colors to identify lines =), But most ASCII editors should do
- (meaning don't use Star Office and save it as a Star Office document for
- instance ;) I will try to explain this as good as I can.
-
- Read through the patch and remove all occurrences of:
-
- * diff -Nur.... that are affecting files YOU have NOT modified. These
- occur when either main or main.dev are a different version (not checked
- out at the same time)
- EVERYTHING from the diff -Nur... line until the next diff -Nur... line
- are changes to the file specified after the diff options, and ONLY that
- file.
-
- * Lines containing "Binary files..." if you add the 'a' switch to -N(a)ur
- binary files will be added to the patch as well, making it huge and
- putting a lot of unnecessary data in it (since you seldom commit any
- binaries).
-
- * If you find changes within a diff block that you don't want to commit
- you can delete them if they are the only changes ranging from the
- @@ -x,y +x,y @@ until the line before the next @@ -x,y +x,y @@. You
- _cannot_ remove single lines after a @@ -x,y +x,y @@ because that will
- break the patch!.
- Example:
- ...
- @@ -15,34 +15,6 @@
- - old_option;
- + new_option;
- @@ -65,13 +65,3 @@
- ...
-
- OK:
- ...
- @@ -65,13 +65,3 @@
- ...
-
- Will break patch:
- ...
- @@ -15,34 +15,6 @@
- old_option;
- @@ -65,13 +65,3 @@
- ...
-
- When I end up in a situation where I have to remove just some lines from
- a block, I leave it alone, remember (write down) which file it is in and
- then edit the file in "main" after I've applied the patch.
-
- * Now it's time for applying the patch to the "main" (stable) directory.
- This should be done in two steps:
- 1. enter "main" and run
-
- patch -p1 --dry-run < ../dev2stable
-
- -p1 means that you are one level deep (that you have entered the
- "main" directory and that should be stripped when patching, if you
- run it from "~/mplayer" you would use -p0).
- --dry-run means that patch does everything it normally does but
- without modifying ANY files. This is a great way of testing whether
- your patch works or not.
- "../dev2stable" is your patchfile. (don't forget the '<')
- If the dry run fails, check the line it failed on and figure out
- why it failed, make a new patch and try again.
-
- 2. OK, you finally have a working patch, remove --dry-run, patch "main"
- and you are done with the patching part =).
-
-4. It's almost time for the final step, committing the changes. But first you
- MUST make sure your changes compile without breaking anything and that it
- follows the Policy mentioned in section 2. (Read it until your eyes are
- bleeding if you want to keep CVS access!)
- Don't worry about object files etc that will be created in your "main" dir,
- they won't be sent to CVS on a commit, you must use the add command to add
- new files (discuss it on dev-eng before adding new files!).
- Now to make sure your additions follow policy do the following on every file
- you will commit:
-
- cvs -z3 diff -u <filename> > <filename.d>
-
- Of course the output file (<filename.d>) can have any name you want. This
- will create a file showing the differences between the file on CVS and your
- updated local file.
- I will explain some of the policy rules I had a hard time understanding:
-
- II.5: This means that if for instance you have lines in <filename.d> that
- look something like this:
-
- -
- +
-
- That means you have added or removed tabs or spaces on that line.
- That qualifies as a cosmetic change and is disallowed. Edit the
- file and put back/remove the added/removed tabs/spaces.
- Rediff the file and make sure the cosmetic changes are fixed.
-
- II.6: Make sure you read and understand this properly before committing
- anything. Commit one file at a time!
-
-5. OK, you have a working patch following the CVS policy, excellent work. Now
- for the final step, committing. This is really simple. Just run the
- following command in "main" for each file you want to commit:
-
- cvs -z3 commit -m "<comment (changes)>" <filename>
- cvs -z3 commit <filename>
-
- The latter will bring up your default text editor for writing comments (I
- prefer this method).
-
-You are done, congratulations. If you are certain you have followed all of the
-policy you shouldn't have any trouble with the CVS maintainers at all.
-At first I thought the policy was too strict, but I discussed it with A'rpi and
-he made some very good points, so don't complain.
More information about the MPlayer-cvslog
mailing list