# HG changeset patch # User diego # Date 1079314656 0 # Node ID f7980032d9cad3f94ca971283f7e29f7d21af804 # Parent 57fd2f36b8cbfb98e2824761ebd4ecac98f8fd85 whitespace cosmetics diff -r 57fd2f36b8cb -r f7980032d9ca DOCS/tech/cvs-howto.txt --- a/DOCS/tech/cvs-howto.txt Sun Mar 14 18:04:59 2004 +0000 +++ b/DOCS/tech/cvs-howto.txt Mon Mar 15 01:37:36 2004 +0000 @@ -34,52 +34,52 @@ As you probably got a restricted CVS-only shell, it's not trivial: ssh LOGIN@mplayerhq.hu passwd - + Replace LOGIN with your login name. Leave 'passwd' unchanged, it's a command. - + Note: If you need a real shell for something, tell A'rpi. 2. Checking out development source tree: - + export CVS_RSH=ssh cvs -z3 -d:ext:LOGIN@mplayerhq.hu:/cvsroot/mplayer co -P main - + Replace LOGIN with your login name. NOTE: cvs -d:pserver: mode doesn't allow writing, even with password! - + 3. Committing changes: cvs -z3 commit -m "comment - what you changed and why" 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 different comments for different files, commit them separately, not at the same time. If you leave out -m at the command line you will be prompted for a comment in an editor (usually vi). - + 4. Adding new files/dirs: cvs add filename/dirname - + 5. Removing files: rm filename cvs remove filename cvs commit -m "reason for removing this file" filename - + 6. Checking changes: - + cvs -z3 diff -u filename(s) - + It's recommended to check changes before committing. especially if you forget what you changed :) This way you will see if your patch has debug stuff or indentation changes and you can fix it before committing and triggering me to use cvs-backup. - + 7. Checking changelog: - cvs -z3 log filename(s) - + cvs -z3 log filename(s) + 8. Renaming/moving files or content of files, removing empty directories: You CANNOT do that. Ask the CVS server admin (A'rpi) to do it! @@ -98,7 +98,7 @@ you can use the 'cvs admin -o' command. Assuming that 1.123 is the latest version of the file and the one you want to remove - cvs -z3 admin -o1.123 filename + cvs -z3 admin -o1.123 filename Do NOT do this unless you really know what you are doing and the version you are removing is the last version, e.g. there were no commits after yours. @@ -133,13 +133,13 @@ for doing things the way we do. Send them as patches to the mailing list, and if the code maintainers say OK, you may commit. This does not apply to files written and/or maintained by you. - + 5. We refuse source indentation and other cosmetical 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.) - - Note: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, + + NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, do NOT change the indentation of the inner part (move it right)! 6. Always fill out the comment at committing (-m switch of CVS, or in the @@ -163,7 +163,7 @@ breaking docs or getting translations or the homepage desynced. If you are unsure about this, send a patch to dev-eng, the documentation maintainers will review and commit your stuff. - + Also read patches.txt !!!! We think our rules are not too hard. If you have comments, contact us. @@ -198,7 +198,7 @@ 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 @@ -213,12 +213,12 @@ 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 @@ -231,29 +231,29 @@ + 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). @@ -263,10 +263,10 @@ "../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 @@ -276,7 +276,7 @@ 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 > Of course the output file () can have any name you want. This @@ -307,7 +307,7 @@ 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