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. Please specify if the key was generated with SSH
40 version 1 or version 2. Detailed instructions are below.
44 It is necessary that everyone with CVS commit access respect and
45 adhere to the following rules. If you ask for and are granted CVS
46 access, you are agreeing to follow these policies.
50 If you are about to commit code to a module, the code that is
51 being committed should be released under the same license as
52 the code that the module has.
54 Check the license if you are unsure, but it is basically:
55 class libraries X11; compiler and tools: GPL; runtime: LGPL.
57 If in doubt, check with the maintainers of the module, or send
58 mail to mono-hackers-list@ximian.com.
62 Even if you have CVS commit access, that doesn't mean you can change
63 code at will in any directory or module. Directories and Namespaces
64 have a sort of unofficial ownership. If you are not the owner of a
65 piece of code and you want to make changes/fixes to it, there are two
67 1) The change is a typo fix or a one-liner build or trivial fix. In
68 this case almost anyone can commit (always remembering to add the
69 proper changelog entry to explain the change). We say "almost anyone",
70 because changes to certain directories almost always should be reviewed
71 first. Such as changes to core stuff: corlib/System, System.Collections,
72 mini/, metadata/, System.IO.
74 2) The change is larger. In this case the patch *must* be sent to
75 mono-devel-list for review by the owner of the code and by the other
76 hackers. Always submit such patches to the list or bugzilla, although
77 you may put the owner of the code in the CC header. Hackers come and go.
78 Mailing a patch to only a personal address is a good way to get the
79 patch forgotten and missed. Plus, getting the patches reviewed as well
80 as reviewing them, is a good thing, so try to get used to it.
82 Note: If the patch is an addition of code and doesn't change any of the
83 existing code, the rules are slightly relaxed: there is more freedom
84 in committing such changes, if they don't interfere with the existing
89 Now, how do you get to be the owner of a chunk of code? The answer is
90 simple. You wrote the code, so you're the unofficial owner. There is
91 also another way. After sending a few patches for the code, the
92 owner (or the core developers of mono, if the owner somehow disappeared)
93 trusts you and tells you you're free to commit without getting his
97 Here is a (partial) list of namespaces/directories with their owners:
99 <li>Debugger module and debug code in mono: martin
100 <li>mcs compiler: miguel, martin, ravi
101 <li>Reflection/Reflection.Emit: lupus, zoltan
103 <li>mini: lupus, dietmar
104 <li>test suite: nickd (though anyone should feel free to add test cases)
105 <li>System.IO: dick, ville
106 <li>security stuff: spouliot
108 <li>System.Web and related: gonzalo
109 <li>System.Xml: eno, piers
110 <li>Remoting: dietmar, lluis
111 <li>interop/marshal: dietmar
115 If you are the owner of a piece of code, feel free to commit code, and
116 delegate the work to others.
118 But, if you're not the owner of the code, committing a rewrite without
119 getting a review first is not good cvsitizenship (especially when the
120 rewrite claimed to fix bugs, but not a single regression test has been
125 Once you know you can commit a patch (because of the rules above) there
126 are a few other small rules to follow:
128 <li>Always add a changelog entry with a meaningful explanation
129 <li>If you fix a bug, add a regression test for it in the regression
131 <li>Don't commit unrelated changes together with a fix: do fine-grained
133 <li>Always check what you're committing: make sure you're only committing
134 what you need and make sure you don't change line endings and
135 whitespace. Do a 'cvs diff -u' of the files you're going to commit and
137 <li>Don't do reformatting commits, unless you're the original author of
139 <li>When fixing bugs, don't follow the documentation blindly, it may
140 well be wrong. Test the behavior on the MS runtime or ask on the list
141 for discussion if unsure. Don't be afraid of having your changes
143 <li>Never remove copyright notices from the code
144 <li>Never remove licensing info from code
145 <li>Never commit code you didn't write yourself or code that doesn't
146 have a suitable license
147 <li>Follow the style conventions
148 <li>Keep an eye on performance considerations, especially for code in
149 core classes, ask on the list for guidance
150 <li>Do a regression test run and a bootstrapping build if making changes
151 to core functionality before committing. Do not commit code that would
152 break the compile, because that wastes everybody's time. Two things
153 are important in this step: trying to build your sources and making
154 sure that you add all the new files before you do a commit.
157 Also, remember to pat yourself on the back after the commit, smile and
158 think we're a step closer to a better free software world.
163 This is a small tutorial for using CVS.
165 ** Generating an SSH key
167 If you are using SSH version 2, please generate your key using:
173 And mail <a href="mailto:miguel@ximian.com">miguel</a> the
176 If you are using SSH version 1, run:
181 And mail <a href="mailto:miguel@ximian.com">miguel</a> your
184 If you are using SSH from SSH Communications Security (they offer
185 a free SSH client for personal use), you have to use OpenSSH to
186 convert your public key to the required format. You have to use
187 OpenSSH's ssh-keygen program and write the following:
190 ssh-keygen -i -f id_XXX.pub > my_public_key.pub
193 where the file id_XXX.pub is your public key file,
194 normally located under ~/.ssh/ or ~/.ssh2/.
195 Send to <a href="mailto:miguel@ximian.com">miguel</a> the
196 my_public_key.pub file.
198 The *exact* format for this file must be:
204 You will need CVS and SSH. Windows users can get both by
205 installing Cygwin (<a
206 href="http://www.cygwin.com">http://www.cygwin.com</a>)
208 Unix users will probably have those tools installed already.
210 ** Checking out the sources
212 To check out the sources for the first time from the
213 repository, use this command:
217 export CVSROOT=username@mono-cvs.ximian.com:/cvs/public
221 ** Updating your sources
223 Every day people will be making changes, to get your latest
224 updated sources, use:
227 cvs -z3 update -Pd mcs mono
230 Note: The '-z3' enables compression for the whole cvs action.
231 The '-Pd' makes the update operation (P)rune directories that
232 have been deleted and get new (d)irectories added to the
237 Usually you will want to make a patch to contribute, and let
238 other people review it before committing it. To obtain such a
242 cd directory-you-want-to-diff
243 cvs -z3 diff -u > file.diff
244 mail mono-list@ximian.com < file.diff
247 ** Committing your work
249 Once you get approval to commit to the CVS, or if you are
250 committing code that you are the maintainer of, you will want
251 to commit your code to CVS.
253 To do this, you have to "add" any new files that you created:
259 And then commit your changes to the repository:
262 cvs commit file-1.cs file-2.cs
267 This is a small tutorial for using SVN (subversion).
271 Follow the cvs instructions above.
273 ** Checking out the sources
275 To checkout the sources for the first time use the command:
277 Note: You should be running 0.35.1 (latest) of svn before attempting
281 svn co svn+ssh://mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
284 If you have a different username on mono-cvs and the local computer
285 you can do the following:
288 svn co svn+ssh://username@mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
293 ** Updating your sources
295 You can update your repository to the latest copy of MonoDevelop by
296 running the following command:
302 from inside your repository.
304 ** Committing your work
306 Before you commit anything, you should first update to the latest
307 sources by following the updating directions. After you are up to date
314 for every file that you have created. You can get a list of these files
321 After all the files are added, run:
327 to commit your changes.
329 ** For more information
331 Look at the MonoDevelop website (coming soon)
333 * Keeping track of changes.
335 We provide two e-mail based mechanisms to keep track of
336 changes to the code base:
339 * <a href="mailto:mono-patches-request@ximian.com">
340 mono-patches@ximian.com</a>: This mailing list receives
341 in patch form all the changes that are being made to the
344 * <a href="mailto:mono-cvs-list-request@ximian.com">
345 mono-cvs-list@ximian.com</a>: This mailing list only
346 receives the CVS commit logs with a list of files
350 We hope to offer LXR and Bonsai in the future as well.
352 To subscribe, send an email message to
353 mono-cvs-list-request@ximian.com and in the body of the
354 message put `subscribe'.
356 This will send you an email message every time a change is
357 made to the CVS repository, together with the information that
358 the author of the changes submitted.
360 You might also want to track the live changes, subscribe to
362 href="mailto:mono-patches-request@ximian.com">mono-patches@ximian.com</a>
363 to receive the patches as they are checked into CVS.