mirror of
https://github.com/mpv-player/mpv
synced 2024-12-25 00:02:13 +00:00
Remove old CVS beginners guide
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18831 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
ivo
parent
04cb555662
commit
cba56d7ff4
@ -199,145 +199,5 @@ We think our rules are not too hard. If you have comments, contact us.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user