Your forks - create a new fork
Log in on to codeplex; go to the R.NET source code tab. You will see a "Fork" link (right hand corner of the figure)

Create your fork. You are free to use whatever name you want for your fork(s)

The process should complete and give you a view of your newly created fork, ready to be cloned to your computer.

There are many clients for Mercurial. This documentation will show a GUI client for Mercurial and Git,
http://sourcetreeapp.com/. This is not an endorsement, and I have no link to the company, it is just what I happen to use personally at the moment.
Start the cloning process of your forked repo:


Once cloned, your local checkout will be the 'default' branch. It may be what you want by the time you read this documentation.

Let's say, as is the case here, that a development branch is ahead and what you want to contribute to. It may or may not be the branch with most recent activity, the tip. for this document, lets say it is.

Doubleclick on the branch you wish to check out.

Now you should see the working copy as being the branch, 'jperraud' in this instance.

It may be optional, but I'd advise you create your own branch by clicking on the "branch" button. You should see a panel where you can name your working branch.

That's it, you have created your branch

Time to look at the code. You'll likely need to work with the solution RDotNet.Tests.sln; since you contribute, you are likely to need to test...

R.NET code uses a somewhat unusual three spaces tab indentation. You can set your C# settings to do so, but to switch back and forth between settings, you should use settings files.


While the R.NET settings we are about to load are mostly standard, you should back up your settings (or at least the C# part of it). If you have customized your settings, you really should back up anyway, to a vssettings file at a location of your choice.

Once you have backed up and are about to load the R.NET settings, click Browse:


Once the file is loaded, you have options to import only a subset of the settings. In this case, there is already a subset only: the ones dealing with C#.

If you are contributing code, in just about any case you should work in a test-driven mode. If your code contribution changes the behavior of R.NET or adds a feature. Ideally you should write a unit test before you change the functionality you are testing. Code contributions without proper unit test coverage are more likely to be (temporarily) rejected, that is until there is unit test is added.

For the sake of demonstrating how to do a pull request, let's add minor changes. The compiler says a couple of variables are unused. We remove them, and save a compile the solution. If you were doing more substantial changes, you would need to iterate until your NUnit tests pass.

Going back to the Mercurial client, it shows the modified files in orange. Refer to Mercurial and SourceTree documentation for details, but you can commit these files.

Always, always add a commit message.

It is commited to your local repository. You may do further work and commits. Let's push this commit now ("Push" button)


Once pushed, of you go back to our web browser and your fork, you can see your commit.

You can then submit a pull request, but you don't have to do this every time your commit/push work to your fork. Just submit a pull request when your overall work is ready. Note that you can specify the source and target branches; in this case we started our branch from the development 'jperraud' branch, so maybe contributions should get back there.


Done. Pending approval.
