SVN

Subversion Repository

Mono uses the Subversion (http://subversion.tigris.org/) source code control system for all of its source code. Although only active contributors get write access to the repository, third party developers and casual users can use our anonymous SVN repository to access the source code as well.

Here we describe how one obtains commit access to the Mono Subversion repository and the responsibilities that come with that access privilege.

Also, you can see our list of important branches.

Browsing the Sources

If all you need is to browse the sources, you can go to anonsvn.mono-project.com and choose between viewvc or websvn interfaces.

Sources are currently being updated every 30 minutes.

Building Mono from source

Once you've obtained the source code for different modules of the Mono project, you'll want to build Mono from source

Following Code Changes

You can subscribe to an RSS feed that tracks the changes to the source code repository. To follow all commits, subscribe to http://razor.occams.info/monorss/feed.cgi?mono:/trunk. You can customize the URL to track only changes in particular directories, e.g.:

Obtaining Write Access

Any active Mono developer can get a SVN 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 SVN Checkouts 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 SVN account send an e-mail to miguel (mailto:miguel@ximian.com) with your public OpenSSH key for this purpose.

Policies

It is necessary that everyone with SVN commit access respect and adhere to the following rules. If you ask for and are granted SVN access, you are agreeing to follow these policies.

Coding Guidelines

We have our own coding guidelines.

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 SVN 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.

  • 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.
  • 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, hari
  • Reflection/Reflection.Emit: lupus, zoltan
  • IO-layer: dick
  • mini: lupus, zoltan, massi
  • 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: grendel/mhabersack
  • System.Xml: eno, piers
  • Remoting: zoltan, lluis
  • interop/marshal: zoltan
  • 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 svnitizenship (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 test 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 svn diff 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
  • Documentation: never copy paste documentation from Visual Studio class view, or MSDN documentation.
  • Never use a decompiler or disassembler to look at proprietary code.
  • 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 SVN

This is a small tutorial for using SVN.

New Section: Windows Tortoise SVN users (next section).

Generating an SSH key

You need to use SSH version 2, then generate your key using: 

 ssh-keygen -t rsa

And mail miguel (mailto:miguel@ximian.com) the id_rsa.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 (mailto:miguel@ximian.com) the my_public_key.pub file.

The format for this file looks like this: 

 ssh-rsa XXXXX....

You will need SVN and SSH. Windows users can get both by installing Cygwin (http://www.cygwin.com). Its a good idea to avoid using putty to handle this as its been known to cause some headaches in the past.

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: 

svn co svn+ssh://USERNAME@mono-cvs.ximian.com/source/trunk/MOD

where USERNAME is your user name and MOD is the module name. Consider using ssh-agent if you get annoyed by ssh asking for a password.

For example: 

  $ svn co svn+ssh://miguel@mono-cvs.ximian.com/source/trunk/mono
  A  mono/libgc
  A  mono/libgc/gc_cpp.cc
  A  mono/libgc/stubborn.c
  A  mono/libgc/blacklst.c

Updating your sources

Every day people will be making changes, to get your latest updated sources, use: 

 svn update mcs mono

Making patches

Usually you will want to make a patch to contribute, and let other people review it before committing it. To obtain such a "patch", you type: 

 cd directory-you-want-to-diff
 svn diff > file.diff

and then mail that file.diff to mono-devel-list.

Committing your work

Once you get approval to commit to the SVN repository, or if you are committing code that you are the maintainer of, you will want to commit your code.

To do this, you have to "add" any new files that you created: 

 svn add new-file.cs

And then commit your changes to the repository: 

 svn commit file-1.cs file-2.cs

Note: Do not forget to provide a ChangeLog detailing your changes.

Resolving Conflicts

Sometimes you will have conflicts between your local changes and changes that someone else did, for example updating a ChangeLog file: 

 $ svn up
 U  mono/configure.in
 C  mono/ChangeLog
 U  mono/README
 Updated to revision 35624
 $ ls -1 mono/ChangeLog.*
 mono/ChangeLog
 mono/ChangeLog.mine
 mono/ChangeLog.r35623
 mono/ChangeLog.r35624

After detecting a conflict, SVN adds the usual conflict markers to the original file (mono/ChangeLog), and also prepares three additional files to help in the merge process: 

* mono/ChangeLog.mine: the locally modified version before the update
* mono/ChangeLog.r35623: the previous version (the version against which the local changes were made)
* mono/ChangeLog.r35624: the new version (the version we were trying to update to)

Resolving the changes can be done by manually editing the file containing the conflict markers (as usually done), or by copying one of the three pure versions over it. After that, it is necessary to inform SVN about the fact the conflict was resolved: 

 $ svn status mono/ChangeLog
 C  ChangeLog
 $ gedit mono/ChangeLog                           # revert local changes
 $ svn resolved mono/ChangeLog
 Resolved conflicted state of 'mono/ChangeLog'
 $ svn status mono/ChangeLog
 M  mono/ChangeLog
 $ ls -1 mono/ChangeLog*
 mono/ChangeLog

Using TortoiseSVN on Windows

This is from Andrew Skiba at Mainsoft: I use TortoiseSVN in parallel with Cygwin SSH on the same directory. Here is how I set it up.

  • Install the full installation of PUTTy
  • Create session called mono-cvs.ximian.com
  • Fill username, give private key path, check option "Don't allocate a pseudo-terminal"
  • Save and open the session. If everything is OK, it will ask you for the passphrase of the private key and close the console window.
  • Now in Tortoise settings set SSH client TortoisePlink.exe.
  • Try to work with the same folder you used for CLI, it will ask you passphrase many times.
  • Use Pageant to remember the passphrase for the whole windows session, it's an analogue of ssh-agent.

See also

Putty and TortoiseSvn

Branches

For details on existing branches, see Branches.

Keeping track of changes

Via Web/Email

It is now possible to subscribe to a special group to track changes to the Mono SVN repository over the web using Google Groups:

Via Email

We provide two e-mail based mechanisms to keep track of changes to the code base:

  • mono-patches (http://lists.ximian.com/mailman/listinfo/mono-patches): This mailing list receives in patch form all the changes that are being made to the SVN. To subscribe, send an email message to mono-patches-request@ximian.com and in the body of the message put `subscribe' or click on the link.
  • mono-cvs-list (http://lists.ximian.com/mailman/listinfo/mono-cvs-list): This mailing list only receives the SVN commit logs with a list of files modified. To subscribe, send an email message to mono-cvs-list-request@ximian.com and in the body of the message put `subscribe' or click on the link.

This will send you an email message every time a change is made to the SVN repository, together with the information that the author of the changes submitted.

Cia.Navi.Cx

The CIA.Navi.Cx project tracks the changes in their page (http://cia.navi.cx/stats/project/mono)