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.

ポリシー

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.

コードのライセンス

もしあなたがモジュールにコードをコミットしようとするときは、コミットしようとしているコードは、そのモジュールのコードと同一のライセンスでリリースされるべきです。

もし不確かであればライセンスをチェックしてください。ただ、一般的には: クラスライブラリはX11、コンパイラおよびツール: GPL、ランタイム: LGPL です。

もし疑わしい点があれば、モジュールの管理者と一緒にチェックするか、あるいは mono-hackers-list@ximian.com にメールしてください。

[訳注 - mono-hackers-listはmono開発者用のメーリングリストで、Ximian(Miguel de Icaza)が登録しなければメンバーになることはできません。ただ、committerであれば、基本的には申し込めば参加できると思います。]

コードを変更する

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. 1) The change is a typo fix or a one-liner build or trivial fix. In this case almost anyone can commit (always remembering to add the proper changelog entry to explain the change). We say "almost anyone", because changes to certain directories almost always should be reviewed first. Such as changes to core stuff: corlib/System, System.Collections, mini/, metadata/, System.IO.

2) The change is larger. In this case the patch *must* be sent to mono-devel-list for review by the owner of the code and by the other hackers. Always submit such patches to the list or bugzilla, although you may put the owner of the code in the CC header. Hackers come and go. Mailing a patch to only a personal address is a good way to get the patch forgotten and missed. Plus, getting the patches reviewed as well as reviewing them, is a good thing, so try to get used to it.

Note: If the patch is an addition of code and doesn't change any of the existing code, the rules are slightly relaxed: there is more freedom in committing such changes, if they don't interfere with the existing codebase.

Owning Code

Now, how do you get to be the owner of a chunk of code? The answer is simple. You wrote the code, so you're the unofficial owner. There is also another way. After sending a few patches for the code, the owner (or the core developers of mono, if the owner somehow disappeared) trusts you and tells you you're free to commit without getting his review first.

Here is a (partial) list of namespaces/directories with their owners:

Debugger module and debug code in mono: martin
mcs compiler: miguel, martin, ravi
Reflection/Reflection.Emit: lupus, zoltan
IO-layer: dick
mini: lupus, dietmar
test suite: nickd (though anyone should feel free to add test cases)
System.IO: dick, ville
security stuff: spouliot
ilasm: jackson
System.Web and related: gonzalo
System.Xml: eno, piers
Remoting: dietmar, lluis
interop/marshal: dietmar
threads: dick

If you are the owner of a piece of code, feel free to commit code, and delegate the work to others.

But, if you're not the owner of the code, committing a rewrite without getting a review first is not good cvsitizenship (especially when the rewrite claimed to fix bugs, but not a single regression test has been added to the suite).

Commit Rules

Once you know you can commit a patch (because of the rules above) there are a few other small rules to follow:

Always add a changelog entry with a meaningful explanation
If you fix a bug, add a regression test for it in the regression suite
Don't commit unrelated changes together with a fix: do fine-grained commits
Always check what you're committing: make sure you're only committing what you need and make sure you don't change line endings and whitespace. Do a 'cvs diff -u' of the files you're going to commit and check the changes.
Don't do reformatting commits, unless you're the original author of the code
When fixing bugs, don't follow the documentation blindly, it may well be wrong. Test the behavior on the MS runtime or ask on the list for discussion if unsure. Don't be afraid of having your changes reviewed.
Never remove copyright notices from the code
Never remove licensing info from code
Never commit code you didn't write yourself or code that doesn't have a suitable license
Follow the style conventions
Keep an eye on performance considerations, especially for code in core classes, ask on the list for guidance
Do a regression test run and a bootstrapping build if making changes to core functionality before committing. Do not commit code that would break the compile, because that 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.

Also, remember to pat yourself on the back after the commit, smile and think we're a step closer to a better free software world.

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 miguel the id_rsa.pub file.

If you are using SSH version 1, run:

	ssh-keygen

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 (http://www.cygwin.com)

Unix users will probably have those tools installed already.

ソースをチェックアウトする

初めてリポジトリからソースをチェックアウトするときは、次のコマンドを使います:

	export CVS_RSH=ssh
	export CVSROOT=username@mono-cvs.ximian.com:/cvs/public
	cvs -z3 co mcs mono

ソースをアップデートする

人々が日々変更を加えています。あなたのソースを最新にアップデートするには:

	cvs -z3 update -Pd mcs mono

備考: '-z3' はすべてのcvsアクションでの圧縮を可能にします。 '-Pd' はアップデート操作が、既に削除されたディレクトリを取り除いて((P)rune)、リポジトリに追加された新しいディレクトリ((d)irectory)を取り込むようにします。

パッチを作る

通常、あなたが貢献するには、パッチを作成して、コミットする前に他の人々がレビューするようにしたいと思うことでしょう。この「パッチ」を作るためには、以下のようにタイプします:

	cd directory-you-want-to-diff
	cvs -z3 diff -u > file.diff
	mail mono-list@ximian.com < file.diff

あなたの成果をコミットする

CVSにコミットできるようになった場合、あるいはあなたがメンテナンス担当者になっているコードをコミットする場合、あなたは自分のコードをCVSにコミットしたいと思うことでしょう。

そのためには、あなたは自分が作った新しいファイルを「追加」しなければなりません:

	cvs add new-file.cs

それから、あなたの変更をリポジトリにコミットする場合は:

	cvs commit file-1.cs file-2.cs

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)

変更を追跡する

われわれは、コードベースの変更を追跡するために、2つのeメールベースの機構を提供しています:

mono-patches@ximian.com: このメーリングリストは、CVSに加えられた変更の全てのパッチを受け取ります。
mono-cvs-list@ximian.com: このメーリングリストは、修正されたファイルのリストを含んだCVSコミットログだけを受け取ります。

将来的には、LXRやBonsaiも同様に提供できれば良いと思っています。

登録するには、mono-cvs-list-request@ximian.com に、メッセージに'subscribe'と書いたeメールメッセージを送ります。

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 mono-patches@ximian.com to receive the patches as they are checked into CVS.

webmaster@go-mono.com