X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fccvs;h=e5a53432682c09a998cae91d5352ef4f31a73d2e;hb=2e99b8d2984d7b3f7b9ca55182481cb939d84b16;hp=c1187d980efc3b58304d036f425cf003199c866b;hpb=1a1cef73cd183d0fd03026914ff1af2739f8568d;p=mono.git diff --git a/web/ccvs b/web/ccvs index c1187d980ef..e5a53432682 100644 --- a/web/ccvs +++ b/web/ccvs @@ -1,25 +1,282 @@ * CVS Access - If you are an active Mono developer, you can get a CVS account - that hosts the Mono source code. + Here we describe how one obtains commit access to the Mono CVS + repository and the responsibilities that come with that access + privilege. - 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. + These only apply to the Mono CVS repository, and not to the Mono + Community repositories at Novell Forge. - If you are using SSH2, please generate your key using: +** What is CVS? + + Briefly, CVS is a system tool used to store and maintain files and + a history of their changes over time. The Mono source code and related + files are kept on a CVS server at Ximian. + +** What Access? + + We mean "commit" access. This is the privilege to make permanent + changes to the Mono source code and related files. You need an account + created by the CVS server administrator in order to commit changes to + the files on that server. + +** How Does One Obtain Access? + + Any active Mono developer can get a CVS account. Normally one is + considered an 'active' developer after sending several patches to the + mailing lists and/or bugzilla for review. + + If you are not a developer, but want to access the latest sources, + please see the AnonCVS + instructions. If you are not a direct contributor to Mono, + but want to host your .NET or Mono-based project, you can use + Novell Forge. + + + If you feel you are ready for a CVS account send an e-mail to + miguel with your public OpenSSH + key for this purpose. We only support SSH2 at this point. + +* Policies + + It is necessary that everyone with CVS commit access respect and + adhere to the following rules. If you ask for and are granted CVS + access, you are agreeing to follow these policies. + +** Code License + + If you are about to commit code to a module, the code that is + being committed 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 mono-hackers-list@ximian.com. + +** Changing code + + Even if you have CVS commit access, that doesn't mean you can change + code at will in any directory or module. Directories and Namespaces + have a sort of unofficial ownership. If you are not the owner of a + piece of code and you want to make changes/fixes to it, there are two + cases. + +
+ cvs co -r mono-1-0 mono + cvs co -r mono-1-0 mcs + cvs co -r mono-1-0 libgdiplus ++ + I personally use a directory called `mono-1-0' to keep these + together and a separate directory keeps my HEAD development, + and I configure each one to different prefixes, so I can test + and run code with HEAD or mono-1-0. + +*** mono-1-0 policy + + This branch will only get bug fixes to critical and major errors. + You must still get approval from the maintainer of the code to + check-in code into this branch. + + Before submitting a patch for this branch, you should run all + appropriate regression tests. Upcoming mono-1.0.x versions + will be produced from this branch. + +*** mono HEAD policy + + HEAD should continue to build at all times: HEAD is not a + dumping ground for partial work: you still must ensure that + the build is not broken, and that no regressions are caused. + Unlike the main branch, you do not need approval to minor + changes, the same old rules apply. + + But for any large architectural change, you must check with + the maintainers and get approval for the patches. For these + large changes, if you are touching someone else's code, you + should contact the maintainer of that code and get approval + from them. + + You must assume that HEAD will be packaged and distributed at + any point, this will be the branch that we use for making the + mono-1.1.x releases that will lead to our stable mono-1.2.x + release. + + So, the bottom line is: do not check-in known regressions that + break the build. A lot of work is underway, and we must + ensure the tree works. + + +* 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:
ssh-keygen -t rsa- And mail me the id_rsa.pub file. + And mail miguel the + id_rsa.pub file. - If you are using SSH1, run: + If you are using SSH version 1, run:
ssh-keygen- And mail me your identity.pub file. + And mail miguel 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: + +
+ ssh-keygen -i -f id_XXX.pub > my_public_key.pub ++ + 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: + +
+ ssh-rsa XXXXX.... +You will need CVS and SSH. Windows users can get both by installing Cygwin ( - cvs -z3 update mcs mono + cvs -z3 update -Pd mcs mono + 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 + other people review it before committing it. To obtain such a "patch", you type:
@@ -59,10 +321,10 @@ mail mono-list@ximian.com < file.diff-** Commiting your work +** Committing 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 + committing 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: @@ -77,10 +339,96 @@ cvs commit file-1.cs file-2.cs -** The Mailing List +* Using SVN + + This is a small tutorial for using SVN (subversion). + For a more complete tutorial on subversion, look at + the svn book + or the svn homepage + +** Generating a key + + Follow the cvs instructions above. + +** Checking out the sources + + To checkout the sources for the first time use the command: + + Note: You should be running 0.35.1 (latest) of svn before attempting + anything here. + +
+ svn co svn+ssh://mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop ++ + If you have a different username on mono-cvs and the local computer + you can do the following: + +
+ svn co svn+ssh://username@mono-cvs.ximian.com/svn/monodevelop/trunk/MonoDevelop ++ + before checking out. + +** Updating your sources + + You can update your repository to the latest copy of MonoDevelop by + running the following command: + +
+ svn up ++ + from inside your repository. + +** Committing your work + + Before you commit anything, you should first update to the latest + sources by following the updating directions. After you are up to date + you need to run a: + +
+ svn add filename ++ + for every file that you have created. You can get a list of these files + by running: + +
+ svn status ++ + After all the files are added, run: + +
+ svn commit ++ + to commit your changes. + +** For more information + + Look at the MonoDevelop website (coming soon) + +* Keeping track of changes. + + We provide two e-mail based mechanisms to keep track of + changes to the code base: + +