| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194 |
- * CVS Access
- If you are an active Mono developer, you can get a CVS account
- that hosts the Mono source code. This web page contains
- details about how to use the CVS server as well as the
- policies to use it.
- 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 OpenSSH key for this
- purpose. Please specify if the key was generated with SSH version 1
- or version 2.
- * Policies
- Here are some policies about the use of the Mono CVS server.
- ** Code License
- If you are about to commit code to a module, the code that is
- being commited should be released under the same license as
- the code that the module has.
- Check the license if you are unsure, but it is basically:
- class libraries X11; compiler and tools: GPL; runtime: LGPL.
- If in doubt, check with the maintainers of the module, or send
- mail to [email protected].
- ** Commiting code.
- If you are the maintainer for a piece of code, feel free to
- commit code, and delegate the work to others.
- 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.
- 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.
- * Using CVS.
- This is a small tutorial for using CVS.
- ** Generating an SSH key
- If you are using SSH version 2, please generate your key using:
- <pre>
- ssh-keygen -t rsa
- </pre>
- And mail me the id_rsa.pub file.
- If you are using SSH version 1, run:
- <pre>
- ssh-keygen
- </pre>
- And mail me your identity.pub file.
- If you are using SSH from SSH Communications Security (they offer
- a free SSH client for personal use), you have to use OpenSSH to
- convert your public key to the required format. You have to use
- OpenSSH's ssh-keygen program and write the following:
- <pre>
- ssh-keygen -i -f id_XXX.pub > my_public_key.pub
- </pre>
-
- where the file id_XXX.pub is your public key file,
- normally located under ~/.ssh/ or ~/.ssh2/.
- Send to miguel the my_public_key.pub file.
- The *exact* format for this file must be:
- <pre>
- ssh-rsa XXXXX....
- </pre>
- 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 Lists
- 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.
- You might also want to track the live changes, subscribe to
- the <a
- href="mailto:[email protected]">[email protected]</a>
- to receive the patches as they are checked into CVS.
- ** Recommendations
- 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.
|