forked from mono/mono
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathccvs
138 lines (99 loc) · 3.78 KB
/
ccvs
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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
* CVS Access
If you are an active Mono developer, you can get a CVS account
that hosts the Mono source code.
If you are not a developer, but want to track the development, please
see the <a href="anoncvs.html">AnonCVS</a> instructions.
Send an e-mail to miguel with your public SSH key for this
purpose. Please specify if the key was generated with SSH1 or SSH2.
If you are using SSH2, please generate your key using:
<pre>
ssh-keygen -t rsa
</pre>
And mail me the id_rsa.pub file.
If you are using SSH1, run:
<pre>
ssh-keygen
</pre>
And mail me your identity.pub file.
You will need CVS and SSH. Windows users can get both by
installing Cygwin (<a
href="http://www.cygwin.com">http://www.cygwin.com</a>)
Unix users will probably have those tools installed already.
** Checking out the sources
To check out the sources for the first time from the
repository, use this command:
<pre>
export CVS_RSH=ssh
export [email protected]:/cvs/public
cvs -z3 co mcs mono
</pre>
** Updating your sources
Every day people will be making changes, to get your latest
updated sources, use:
<pre>
cvs -z3 update -Pd mcs mono
</pre>
Note: The '-z3' enables compression for the whole cvs action.
The '-Pd' makes the update operation (P)rune directories that
have been deleted and get new (d)irectories added to the
repository.
** Making patches
Usually you will want to make a patch to contribute, and let
other people review it before commiting it. To obtain such a
"patch", you type:
<pre>
cd directory-you-want-to-diff
cvs -z3 diff -u > file.diff
mail [email protected] < file.diff
</pre>
** Keeping track of changes.
We provide two e-mail based mechanisms to keep track of
changes to the code base:
<ul>
* <a href="mailto:[email protected]">
[email protected]</a>: This mailing list receives
in patch form all the changes that are being made to the
CVS.
* <a href="mailto:[email protected]">
[email protected]</a>: This mailing list only
receives the CVS commit logs with a list of files
modified.
</ul>
We hope to offer LXR and Bonsai in the future as well.
** Commiting your work
Once you get approval to commit to the CVS, or if you are
commiting code that you are the maintainer of, you will want
to commit your code to CVS.
To do this, you have to "add" any new files that you created:
<pre>
cvs add new-file.cs
</pre>
And then commit your changes to the repository:
<pre>
cvs commit file-1.cs file-2.cs
</pre>
** The Mailing List
To keep track of the various development and changes to the
CVS tree, you can subscribe to the [email protected].
To subscribe, send an email message to
[email protected] and in the body of the
message put `subscribe'.
This will send you an email message every time a change is
made to the CVS repository, together with the information that
the author of the changes submitted.
** Recommendations
Please do not commit code that would break the compile to the
CVS, because that normally wastes everybody's time. Two things
are important in this step: trying to build your sources and making
sure that you add all the new files before you do a commit.
To build the sources, most of the type trying the `make' command
is enough. In some cases (the class libraries) we use nant, so
you need to run nant manually.
Use ChangeLog entries so we can keep textual descriptions of
your work, and use the contents of your ChangeLog file as the
CVS commit message (ie, paste the contents of this into the
editor buffer).
If you are making changes to someone else's code, please make
sure you get in touch with the maintainer of that code before
applying patches. You want to avoid commiting conflicting
work to someone else's code.