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
66 1) The change is a typo fix or a one-liner build or trivial fix. In
67 this case almost anyone can commit (always remembering to add the
68 proper changelog entry to explain the change). We say "almost anyone",
69 because changes to certain directories almost always should be reviewed
70 first. Such as changes to core stuff: corlib/System, System.Collections,
71 mini/, metadata/, System.IO.
73 2) The change is larger. In this case the patch *must* be sent to
74 mono-devel-list for review by the owner of the code and by the other
75 hackers. Always submit such patches to the list or bugzilla, although
76 you may put the owner of the code in the CC header. Hackers come and go.
77 Mailing a patch to only a personal address is a good way to get the
78 patch forgotten and missed. Plus, getting the patches reviewed as well
79 as reviewing them, is a good thing, so try to get used to it.
81 Note: If the patch is an addition of code and doesn't change any of the
82 existing code, the rules are slightly relaxed: there is more freedom
83 in committing such changes, if they don't interfere with the existing
88 Now, how do you get to be the owner of a chunk of code? The answer is
89 simple. You wrote the code, so you're the unofficial owner. There is
90 also another way. After sending a few patches for the code, the
91 owner (or the core developers of mono, if the owner somehow disappeared)
92 trusts you and tells you you're free to commit without getting his
96 Here is a (partial) list of namespaces/directories with their owners:
98 <li>Debugger module and debug code in mono: martin
99 <li>mcs compiler: miguel, martin, ravi
100 <li>Reflection/Reflection.Emit: lupus, zoltan
102 <li>mini: lupus, dietmar
103 <li>test suite: nickd (though anyone should feel free to add test cases)
104 <li>System.IO: dick, ville
105 <li>security stuff: spouliot
107 <li>System.Web and related: gonzalo
108 <li>System.Xml: eno, piers
109 <li>Remoting: dietmar, lluis
110 <li>interop/marshal: dietmar
114 If you are the owner of a piece of code, feel free to commit code, and
115 delegate the work to others.
117 But, if you're not the owner of the code, committing a rewrite without
118 getting a review first is not good cvsitizenship (especially when the
119 rewrite claimed to fix bugs, but not a single regression test has been
124 Once you know you can commit a patch (because of the rules above) there
125 are a few other small rules to follow:
127 <li>Always add a changelog entry with a meaningful explanation
128 <li>If you fix a bug, add a regression test for it in the regression
130 <li>Don't commit unrelated changes together with a fix: do fine-grained
132 <li>Always check what you're committing: make sure you're only committing
133 what you need and make sure you don't change line endings and
134 whitespace. Do a 'cvs diff -u' of the files you're going to commit and
136 <li>Don't do reformatting commits, unless you're the original author of
138 <li>When fixing bugs, don't follow the documentation blindly, it may
139 well be wrong. Test the behavior on the MS runtime or ask on the list
140 for discussion if unsure. Don't be afraid of having your changes
142 <li>Never remove copyright notices from the code
143 <li>Never remove licensing info from code
144 <li>Never commit code you didn't write yourself or code that doesn't
145 have a suitable license
146 <li>Follow the style conventions
147 <li>Keep an eye on performance considerations, especially for code in
148 core classes, ask on the list for guidance
149 <li>Do a regression test run and a bootstrapping build if making changes
150 to core functionality before committing. Do not commit code that would
151 break the compile, because that wastes everybody's time. Two things
152 are important in this step: trying to build your sources and making
153 sure that you add all the new files before you do a commit.
156 Also, remember to pat yourself on the back after the commit, smile and
157 think we're a step closer to a better free software world.
162 This is a small tutorial for using CVS.
164 ** Generating an SSH key
166 If you are using SSH version 2, please generate your key using:
172 And mail <a href="mailto:miguel@ximian.com">miguel</a> the
175 If you are using SSH version 1, run:
180 And mail <a href="mailto:miguel@ximian.com">miguel</a> your
183 If you are using SSH from SSH Communications Security (they offer
184 a free SSH client for personal use), you have to use OpenSSH to
185 convert your public key to the required format. You have to use
186 OpenSSH's ssh-keygen program and write the following:
189 ssh-keygen -i -f id_XXX.pub > my_public_key.pub
192 where the file id_XXX.pub is your public key file,
193 normally located under ~/.ssh/ or ~/.ssh2/.
194 Send to <a href="mailto:miguel@ximian.com">miguel</a> the
195 my_public_key.pub file.
197 The *exact* format for this file must be:
203 You will need CVS and SSH. Windows users can get both by
204 installing Cygwin (<a
205 href="http://www.cygwin.com">http://www.cygwin.com</a>)
207 Unix users will probably have those tools installed already.
209 ** Checking out the sources
211 To check out the sources for the first time from the
212 repository, use this command:
216 export CVSROOT=username@mono-cvs.ximian.com:/cvs/public
220 ** Updating your sources
222 Every day people will be making changes, to get your latest
223 updated sources, use:
226 cvs -z3 update -Pd mcs mono
229 Note: The '-z3' enables compression for the whole cvs action.
230 The '-Pd' makes the update operation (P)rune directories that
231 have been deleted and get new (d)irectories added to the
236 Usually you will want to make a patch to contribute, and let
237 other people review it before committing it. To obtain such a
241 cd directory-you-want-to-diff
242 cvs -z3 diff -u > file.diff
243 mail mono-list@ximian.com < file.diff
246 ** Committing your work
248 Once you get approval to commit to the CVS, or if you are
249 committing code that you are the maintainer of, you will want
250 to commit your code to CVS.
252 To do this, you have to "add" any new files that you created:
258 And then commit your changes to the repository:
261 cvs commit file-1.cs file-2.cs
266 This is a small tutorial for using SVN (subversion).
267 For a more complete tutorial on subversion, look at
268 <a href="http://svnbook.red-bean.com/">the svn book</a>
269 or <a href="http://subversion.tigris.org">the svn homepage</a>
273 Follow the cvs instructions above.
275 ** Checking out the sources
277 To checkout the sources for the first time use the command:
279 Note: You should be running 0.35.1 (latest) of svn before attempting
283 svn co svn+ssh://mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
286 If you have a different username on mono-cvs and the local computer
287 you can do the following:
290 svn co svn+ssh://username@mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop
295 ** Updating your sources
297 You can update your repository to the latest copy of MonoDevelop by
298 running the following command:
304 from inside your repository.
306 ** Committing your work
308 Before you commit anything, you should first update to the latest
309 sources by following the updating directions. After you are up to date
316 for every file that you have created. You can get a list of these files
323 After all the files are added, run:
329 to commit your changes.
331 ** For more information
333 Look at the MonoDevelop website (coming soon)
335 * Keeping track of changes.
337 We provide two e-mail based mechanisms to keep track of
338 changes to the code base:
341 * <a href="mailto:mono-patches-request@ximian.com">
342 mono-patches@ximian.com</a>: This mailing list receives
343 in patch form all the changes that are being made to the
346 * <a href="mailto:mono-cvs-list-request@ximian.com">
347 mono-cvs-list@ximian.com</a>: This mailing list only
348 receives the CVS commit logs with a list of files
352 We hope to offer LXR and Bonsai in the future as well.
354 To subscribe, send an email message to
355 mono-cvs-list-request@ximian.com and in the body of the
356 message put `subscribe'.
358 This will send you an email message every time a change is
359 made to the CVS repository, together with the information that
360 the author of the changes submitted.
362 You might also want to track the live changes, subscribe to
364 href="mailto:mono-patches-request@ximian.com">mono-patches@ximian.com</a>
365 to receive the patches as they are checked into CVS.