1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
About CVS write access: by A'rpi
~~~~~~~~~~~~~~~~~~~~~~~
I. TECH SIDE:
=============
1. Changing password:
As you probably got a restricted CVS-only shell, it's not trivial:
ssh LOGIN@mplayerhq.hu passwd
(replace LOGIN with your loginname. leave 'passwd' unchanged, it's command)
Note: if you need real shell for something, tell me.
2. Checkout devel. source tree:
export CVS_RSH=ssh
cvs -z3 -d:ext:LOGIN@mplayerhq.hu:/cvsroot/mplayer co main
NOTE: cvs -d:pserver: mode doesn't allow writting, even with password!
3. Commiting changes:
cvs -z3 commit -m "comment - what and why did you change" filename(s)
Do not use such comments: "bugfix." or "files changed" or "dunno"
You don't have to include filename in comment, as comments are linked
to files. If you have different comments for files, commit them separated,
not at same time.
4. Adding new files/dirs:
cvs add filename/dirname
5. Removing files:
rm filename
cvs remove filename
6. Check changes:
cvs -z3 diff -u filename(s)
it's recommended to check changes first, before commit. especially if you
forget what did you change :)
and this way you will see if your patch has debug stuff or indenting change,
and you can fix it before commiting and triggering me to use cvs-backup.
7. Check changelog:
cvs -z3 log filename(s)
8. Rename/move files:
you can NOT do that. ask CVS server admin (A'rpi) to do it!
do NOT remove & re-add file - it will kill changelog!!!!
If you have any tech problems with cvs server, contact me:
A'rpi <arpi@thot.banki.hu>
II. POLICY / RULES:
===================
1. You shouldn't commit code which makes cvs broken!
(i mean unfinished but enabled code which break
compiling or compiles but does not work)
2. You don't have over-test things. if it works for you,
and you think it should work for others too, then commit.
If it has problems (portability, exploits compiler bugs,
unusual environment etc) they will be reported, it's ok.
3. You can commit unfinished stuff (for testing etc), but it
must be disabled (#ifdef etc) by default.
4. Do not change behaviour of the program (renaming options etc)
without discussing first at the MPlayer-dev-eng list.
5. Source indenting and other cosmetical changes are refused.
I'll remove those commits...
Every developer has its own indenting style, you shouldn't
change it. Of course if you (re)write something then you can
use your own style...
(Many projects forces a given indenting style - we don't)
6. Always fill out the comment at commiting (-m switch of cvs, or
in the editor if you left -m).
It shouldn't be such lines: "fixed!" or "Changed it."
Describe in a few lines (usually 1 line is enough) what did
you changed and why did you that. You can refer mails if bugfix.
7. If you apply patch by someone else, include his name and email
in the cvs comment!
8. I've developed something called CVS-Backup. It archives CVS
repository after each commit - so I can reverse your commits
(without messing up changelog) if they are bad.
If you think your bugfix or other change was bad and unneeded,
ask me to reverse it instead of commiting previous version!
I think our rules aren't too hard. If you have comments, contact me.
|
