3 Here we describe how one obtains commit access to the Mono CVS
4 repository and the responsibilities that come with that access
7 These only apply to the Mono CVS repository, and not to the <a
8 href="http://forge.novell.com/modules/xfmod/community/?monocomm">Mono
9 Community</a> repositories at Novell Forge.
13 Briefly, CVS is a system tool used to store and maintain files and
14 a history of their changes over time. The Mono source code and related
15 files are kept on a CVS server at Ximian.
19 We mean "commit" access. This is the privilege to make permanent
20 changes to the Mono source code and related files. You need an account
21 created by the CVS server administrator in order to commit changes to
22 the files on that server.
24 ** How Does One Obtain Access?
26 Any active Mono developer can get a CVS account. Normally one is
27 considered an 'active' developer after sending several patches to the
28 mailing lists and/or bugzilla for review.
30 If you are not a developer, but want to access the latest sources,
31 please see the <a href="anoncvs.html">AnonCVS</a>
32 instructions. If you are not a direct contributor to Mono,
33 but want to host your .NET or Mono-based project, you can use
34 <a href="forge.html">Novell Forge</a>.
37 If you feel you are ready for a CVS account send an e-mail to
38 <a href="mailto:miguel@ximian.com">miguel</a> with your public OpenSSH
39 key for this purpose. We only support SSH2 at this point.
43 It is necessary that everyone with CVS commit access respect and
44 adhere to the following rules. If you ask for and are granted CVS
45 access, you are agreeing to follow these policies.
49 If you are about to commit code to a module, the code that is
50 being committed should be released under the same license as
51 the code that the module has.
53 Check the license if you are unsure, but it is basically:
54 class libraries X11; compiler and tools: GPL; runtime: LGPL.
56 If in doubt, check with the maintainers of the module, or send
57 mail to mono-hackers-list@ximian.com.
61 Even if you have CVS commit access, that doesn't mean you can change
62 code at will in any directory or module. Directories and Namespaces
63 have a sort of unofficial ownership. If you are not the owner of a
64 piece of code and you want to make changes/fixes to it, there are two
68 <li> The change is a typo fix or a one-liner build or trivial fix. In
69 this case almost anyone can commit (always remembering to add the
70 proper changelog entry to explain the change). We say "almost anyone",
71 because changes to certain directories almost always should be reviewed
72 first. Such as changes to core stuff: corlib/System, System.Collections,
73 mini/, metadata/, System.IO.
75 <li> The change is larger. In this case the patch *must* be sent to
76 mono-devel-list for review by the owner of the code and by the other
77 hackers. Always submit such patches to the list or bugzilla, although
78 you may put the owner of the code in the CC header. Hackers come and go.
79 Mailing a patch to only a personal address is a good way to get the
80 patch forgotten and missed. Plus, getting the patches reviewed as well
81 as reviewing them, is a good thing, so try to get used to it.
84 Note: If the patch is an addition of code and doesn't change any of the
85 existing code, the rules are slightly relaxed: there is more freedom
86 in committing such changes, if they don't interfere with the existing
91 Now, how do you get to be the owner of a chunk of code? The answer is
92 simple. You wrote the code, so you're the unofficial owner. There is
93 also another way. After sending a few patches for the code, the
94 owner (or the core developers of mono, if the owner somehow disappeared)
95 trusts you and tells you you're free to commit without getting his
99 Here is a (partial) list of namespaces/directories with their owners:
101 <li>Debugger module and debug code in mono: martin
102 <li>mcs compiler: miguel, martin, ravi
103 <li>Reflection/Reflection.Emit: lupus, zoltan
105 <li>mini: lupus, dietmar
106 <li>test suite: nickd (though anyone should feel free to add test cases)
107 <li>System.IO: dick, ville
108 <li>security stuff: spouliot
110 <li>System.Web and related: gonzalo
111 <li>System.Xml: eno, piers
112 <li>Remoting: dietmar, lluis
113 <li>interop/marshal: dietmar
117 If you are the owner of a piece of code, feel free to commit code, and
118 delegate the work to others.
120 But, if you're not the owner of the code, committing a rewrite without
121 getting a review first is not good cvsitizenship (especially when the
122 rewrite claimed to fix bugs, but not a single regression test has been
127 Once you know you can commit a patch (because of the rules above) there
128 are a few other small rules to follow:
131 <li>Always add a ChangeLog entry with a meaningful
132 explanation, this file should be located in the same directory
133 as the change you make.
135 <li>The ChangeLog entry <b>must</b> be pasted on the CVS
136 commit log, so the CVS commit log can be used to map to the
139 <li>The ChangeLog and the files that comprise related changes
140 should be committed together, not one by one, otherwise the
141 history is pretty much useless if related changes are
142 separated during the commit.
144 <li>If you fix a bug, add a regression test for it in the regression
147 <li>Don't commit unrelated changes together with a fix: do fine-grained
150 <li>Always check what you're committing: make sure you're only committing
151 what you need and make sure you don't change line endings and
152 whitespace. Do a 'cvs diff -u' of the files you're going to commit and
155 <li>Don't do reformatting commits, unless you're the original author of
158 <li>When fixing bugs, don't follow the documentation blindly, it may
159 well be wrong. Test the behavior on the MS runtime or ask on the list
160 for discussion if unsure. Don't be afraid of having your changes
163 <li>Never remove copyright notices from the code.
165 <li>Never remove licensing info from code.
167 <li>Never commit code you didn't write yourself or code that doesn't
168 have a suitable license.
170 <li>Follow the style conventions.
172 <li>Keep an eye on performance considerations, especially for code in
173 core classes, ask on the list for guidance.
175 <li>Do a regression test run and a bootstrapping build if making changes
176 to core functionality before committing. Do not commit code that would
177 break the compile, because that wastes everybody's time. Two things
178 are important in this step: trying to build your sources and making
179 sure that you add all the new files before you do a commit.
183 Also, remember to pat yourself on the back after the commit, smile and
184 think we're a step closer to a better free software world.
188 We have branched the CVS modules `mono', `mcs' and
189 `libgdiplus', the tag to fetch these branches is: `mono-1-0',
190 so you use the following command to fetch the mono-1-0
194 cvs co -r mono-1-0 mono
195 cvs co -r mono-1-0 mcs
196 cvs co -r mono-1-0 libgdiplus
199 I personally use a directory called `mono-1-0' to keep these
200 together and a separate directory keeps my HEAD development,
201 and I configure each one to different prefixes, so I can test
202 and run code with HEAD or mono-1-0.
206 This branch will only get bug fixes to critical and major errors.
207 You must still get approval from the maintainer of the code to
208 check-in code into this branch.
210 Before submitting a patch for this branch, you should run all
211 appropriate regression tests. Upcoming mono-1.0.x versions
212 will be produced from this branch.
216 HEAD should continue to build at all times: HEAD is not a
217 dumping ground for partial work: you still must ensure that
218 the build is not broken, and that no regressions are caused.
219 Unlike the main branch, you do not need approval to minor
220 changes, the same old rules apply.
222 But for any large architectural change, you must check with
223 the maintainers and get approval for the patches. For these
224 large changes, if you are touching someone else's code, you
225 should contact the maintainer of that code and get approval
228 You must assume that HEAD will be packaged and distributed at
229 any point, this will be the branch that we use for making the
230 mono-1.1.x releases that will lead to our stable mono-1.2.x
233 So, the bottom line is: do not check-in known regressions that
234 break the build. A lot of work is underway, and we must
235 ensure the tree works.
240 This is a small tutorial for using CVS.
242 ** Generating an SSH key
244 If you are using SSH version 2, please generate your key using:
250 And mail <a href="mailto:miguel@ximian.com">miguel</a> the
253 If you are using SSH version 1, run:
258 And mail <a href="mailto:miguel@ximian.com">miguel</a> your
261 If you are using SSH from SSH Communications Security (they offer
262 a free SSH client for personal use), you have to use OpenSSH to
263 convert your public key to the required format. You have to use
264 OpenSSH's ssh-keygen program and write the following:
267 ssh-keygen -i -f id_XXX.pub > my_public_key.pub
270 where the file id_XXX.pub is your public key file,
271 normally located under ~/.ssh/ or ~/.ssh2/.
272 Send to <a href="mailto:miguel@ximian.com">miguel</a> the
273 my_public_key.pub file.
275 The *exact* format for this file must be:
281 You will need CVS and SSH. Windows users can get both by
282 installing Cygwin (<a
283 href="http://www.cygwin.com">http://www.cygwin.com</a>)
285 Unix users will probably have those tools installed already.
287 ** Checking out the sources
289 To check out the sources for the first time from the
290 repository, use this command:
294 export CVSROOT=username@mono-cvs.ximian.com:/cvs/public
298 ** Updating your sources
300 Every day people will be making changes, to get your latest
301 updated sources, use:
304 cvs -z3 update -Pd mcs mono
307 Note: The '-z3' enables compression for the whole cvs action.
308 The '-Pd' makes the update operation (P)rune directories that
309 have been deleted and get new (d)irectories added to the
314 Usually you will want to make a patch to contribute, and let
315 other people review it before committing it. To obtain such a
319 cd directory-you-want-to-diff
320 cvs -z3 diff -u > file.diff
321 mail mono-list@ximian.com < file.diff
324 ** Committing your work
326 Once you get approval to commit to the CVS, or if you are
327 committing code that you are the maintainer of, you will want
328 to commit your code to CVS.
330 To do this, you have to "add" any new files that you created:
336 And then commit your changes to the repository:
339 cvs commit file-1.cs file-2.cs
344 This is a small tutorial for using SVN (subversion).
345 For a more complete tutorial on subversion, look at
346 <a href="http://svnbook.red-bean.com/">the svn book</a>
347 or <a href="http://subversion.tigris.org">the svn homepage</a>
351 Follow the cvs instructions above.
353 ** Checking out the sources
355 To checkout the sources for the first time use the command:
357 Note: You should be running 0.35.1 (latest) of svn before attempting
361 svn co svn+ssh://mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
364 If you have a different username on mono-cvs and the local computer
365 you can do the following:
368 svn co svn+ssh://username@mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
373 ** Updating your sources
375 You can update your repository to the latest copy of MonoDevelop by
376 running the following command:
382 from inside your repository.
384 ** Committing your work
386 Before you commit anything, you should first update to the latest
387 sources by following the updating directions. After you are up to date
394 for every file that you have created. You can get a list of these files
401 After all the files are added, run:
407 to commit your changes.
409 ** For more information
411 Look at the MonoDevelop website (coming soon)
413 * Keeping track of changes.
415 We provide two e-mail based mechanisms to keep track of
416 changes to the code base:
419 * <a href="mailto:mono-patches-request@ximian.com">
420 mono-patches@ximian.com</a>: This mailing list receives
421 in patch form all the changes that are being made to the
424 * <a href="mailto:mono-cvs-list-request@ximian.com">
425 mono-cvs-list@ximian.com</a>: This mailing list only
426 receives the CVS commit logs with a list of files
430 We hope to offer LXR and Bonsai in the future as well.
432 To subscribe, send an email message to
433 mono-cvs-list-request@ximian.com and in the body of the
434 message put `subscribe'.
436 This will send you an email message every time a change is
437 made to the CVS repository, together with the information that
438 the author of the changes submitted.
440 You might also want to track the live changes, subscribe to
442 href="mailto:mono-patches-request@ximian.com">mono-patches@ximian.com</a>
443 to receive the patches as they are checked into CVS.