Tags: | Categories: Blog Posted by al on 5/19/2011 11:22 PM | Comments (0)

I started looking at the source code for the open source project NuGet, besides being a fantastic template of how code should be written, is actually a great learning tool of how properly set up a open source project or even any development project on the enterprise. One thing I’m enjoying is being able to work with the new version and use it to install packages. Having always a newer version makes me smile.

Package Manager Console Host Version

The Outer Curve Foundation http://www.outercurve.org/ manages NuGet and they are doing a fantastic and responsive job for an open source project. They set up workflows that can shame many huge corporates. I may don’t like much the source control they selected, maybe because I spent too long in VSS and TFS myself. Yet looks like gets the job done nicely.

Source Control

You’ll need to install Tortoise HG that includes the Mercurial command line. You can download Tortoise from here http://tortoisehg.bitbucket.org/download/index.html

All source code for NuGet can be found and download it here using the command line. You could just create an empty directory and then call to download all source code.

hg clone https://hg01.codeplex.com/nuget

However, there are only the main core developers that have access to check in into the main branch, for this the recommendation is to go to the Source Code tab at Codeplex and click Create Fork, that will copy the latest dataset to your own branch and will provide you read and write permissions. Now you can call:

hg clone https://hg01.codeplex.com/forks/yourusername/yourforkname

then grab all the files

hg pull

Now you can work from that fork, without polluting the main branch. To push your changes, first commit and then push

hg commit –m “This is my changes for issue number 829” –u yourusername

hg push

And enter your username and password when prompt it. Now all your changes will be save on the server and will be ready to submit it for code review.

Code Review

Most companies code review is not as well organized, Nuget users reviewboard http://docs.nuget.org/docs/contribute/code-reviews that allows them to review the diff code and approve it to add it into the main branch. There is a lot of work for developers to fork the code to have their own branch, yet, nobody but the core team can break the main branch. Anybody submitting code should first post a message about what code they are going to make changes and then, after the blessing from the team, they can submit the review.

They have installed http://www.reviewboard.org/ into http://reviewboard.nupack.com/ would be nice if they used http://reviewboard.nuget.com yet we need to remember that nupack was the previous name of nuget.

To submit your review, you need to submit your fork. There are a few steps and I’m still learning those. The idea is to get an extension called postreview, then you can call the review and the best way was interactive:

hg postreview –I

I got an error so David Fowler kindly told me that I need it to merge it back to the main first. However didn’t fix the issue. I’m sure that I was doing something wrong.

hg pull https://hg01.codeplex.com/nuget

hg up default

hg merge c781935efe12 // this is the changeset number

The full error is:

** unknown exception encountered, please report by visiting
**  http://mercurial.selenic.com/wiki/BugTracker
** Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 1.8.2)
** Extensions loaded: fixfrozenexts, reviewboard
Traceback (most recent call last):
  File "hg", line 36, in <module>
  File "mercurial\dispatch.pyo", line 16, in run
  File "mercurial\dispatch.pyo", line 36, in dispatch
  File "mercurial\dispatch.pyo", line 58, in _runcatch
  File "mercurial\dispatch.pyo", line 601, in _dispatch
  File "mercurial\dispatch.pyo", line 406, in runcommand
  File "mercurial\dispatch.pyo", line 655, in _runcommand
  File "mercurial\dispatch.pyo", line 609, in checkargs
  File "mercurial\dispatch.pyo", line 598, in <lambda>
  File "mercurial\util.pyo", line 433, in check
  File "C:\mercurialextensions\mercurial-reviewboard\mercurial-reviewboard\mercu
rial_reviewboard\__init__.py", line 68, in postreview
    send_review(ui, repo, c, parent, diff, parentdiff, opts)
  File "C:\mercurialextensions\mercurial-reviewboard\mercurial-reviewboard\mercu
rial_reviewboard\__init__.py", line 127, in send_review
  File "C:\mercurialextensions\mercurial-reviewboard\mercurial-reviewboard\mercu
rial_reviewboard\__init__.py", line 214, in new_review
    raise util.Abort(_(msg))
  File "mercurial\i18n.pyo", line 39, in gettext
AttributeError: 'ReviewBoardError' object has no attribute 'split'


Coding Guidelines

Simple code guidelines with examples is what keeps developers successful and without stressing out on making sure all their code fulfills all requirements.

Issue Tracker

The NuGet project uses codeplex for issue tracking and discussion of new features. By having the issue tracker at codeplex, because very visible to anybody to find out what bugs are standing and to vote in the bugs to be fixed. Before working on an issue of feature request, you should add a comment to let the administrators that somebody is taking care of it. So 2 people don’t work in the same issue.

Continuous Integration

This is properly the coolest part of all, we all started projects and set up automated builds and tests, yet most of the time, let’s face it, takes too long to set up and we avoid that step. The NuGet project is making it look very easy by using TeamCity, a very simple continuous integration tool that many companies should start using. You can see their TeamCity server installed here http://ci.nuget.org:8080/

I do believe that any developer should get involved in the NuGet project for the simple reason of learning. It’s as essential as doing some training or watching some presentations on the latest MVC 3 Razor markup changes. NuGet is how any development project should be approached.



blog comments powered by Disqus