Software Development Process

Code Conventions

Java code will follow the Java code conventions but must use spaces, not tabs, for indentation.
C# code will follow the .NET Framework Design Guidelines

Code Repository

Code is maintained at the Google Code Repository.

The repository uses Mercurial for source code management. You can download a copy of Mercurial for your platform at the Mercurial site.

The best introduction to Mercurial is: [1]. If you have used CVS or Subversion in the past, it may take a bit of time to get used to Mercurial; reading the introduction is highly recommended. There are also a number of quick tutorials, either at the Mercurial main site or [2]

If you just want a few commands to get started, here they are. If Mercurial isn't doing what you expect, read the above, or get in touch with Arien or Brian. Don't ever use a force command.

# pull the code from repository on google code
 hg clone https://nhin-d.googlecode.com/hg/ nhin-d
 # fetch the latest changes
 hg fetch
 # hack some code, added some files
 hg add /path/to/my/really/cool/file.java
 hg com -m "comment"
 # hack some more
 # what did I change?
 hg stat
 # oops
 hg revert /path/to/really/stupid/change.java
 # hack some more code
 hg com -m "comment"
 # unit tests all pass -- we're done. Let's make sure our changeset has what we expect
 hg stat
 # Get ready to push to the main repository by fetching changes -- automatically merges latest changes back in
 hg fetch
 # What changes need to be pushed up to the sky?
 hg outgoing
 # OK, everything merged, push it back
 hg push
 # Never ever ever ever do this, even when Mercurial says you can
 hg push -f

To get started:

1. Get a build of Mercurial for your OS: [3]
2. (Recommended) download KDiff3 for your platform [4] -- If you have a preferred diff/merge tool, Google for instructions to use it in the Mercurial workflow
3. Create an ~/.hgrc file (or Mercurial.ini for Windows: see the tutorial listed above for configuration location on Windows)
4. Add the following to the ~/.hgrc file

[ui]
username = Your Name <youremail@yourorg.org>
verbose = True

[auth]
nhind.prefix = https://nhin-d.googlecode.com/hg/
nhind.username = yourgoogleid@gmail.com
nhind.password = yourgooglecodepw

[extensions]
hgext.extdiff =
hgext.fetch=

[extdiff]
cmd.kdiff3 =

[merge-tools]
kdiff3.args = $base $local $other -o $output

You will find your Google Code password at the Google Code settings page. This is not your Google account password so storing it in the ~/.hgrc file is low risk, but please keep the credentials secure to prevent malicious edits to the repository (like the Wiki, since the repository contains the full change history, the risk of such edits is also low). If you do not wish to store your password locally, you may omit the password in the [auth] section and type it each time.

Commit Email Messages

We highly recommend that if you are doing active development, you also subscribe to the nhindirect-commits mailing list. Commit messages include the description of the change, the branch the changes are applied to, and a text diff of the changes. This makes following the messages a useful way to do post-commit review of the changes, and helping build a broader understanding of the changes taking place.

Source code organization

The repository contains root level directories for each module. Under the root level directory is a subdirectory for each implementation. The subdirectories are named by language:

Language	Subdirectory Name
Java	java
C# .Net	csharp

For example:

/
 --/java
 ----/agent
 ----/dns
 --/csharp
 ----/agent
 ----/dns

Basic code management workflow

Maintainers

1. All code checked in must have test automation (unit tests or integration tests), and must pass all tests, including integration smoke tests
2. Keep features small and well-tested
3. Develop your feature, checking in to your local copy of the repository, and pulling from the main repository frequently
4. When test automation passes against an up-to-date pull of the main repository, push changes back

Non Maintainers

1. Create a clone of the repository
2. Follow the above rules relating to feature size and test automation
3. When your feature is complete, send a pull request to a main repository maintainer