Code Review process

[Jay Beavers]

I have a patch I'd like to commit to the depot.  It includes adding the xUnit 1.5 binaries and adding a library engine dll.

I attempted to follow the "submit an issue of template 'code review'" process but this didn't work very well because the issue tracker insisted I "include the branch path".  This confused me because we don't have 'branch paths' in HG projects to the best of my understanding, I think this template assumes a subversion-like approach to source management.

I exported my changes using hg bundle (have have 2 commits, a simple hg export didn't seem to be the right approach).  I would have attached the file here but it's 1.6 MB since it includes the xUnit binaries and I didn't want to spam everyone's inbox with a large attachment.

Suggestions on how to proceed?  I'm working on setting up my dev box to be http visible so I can "hg serve" my repository, but I'm having to go through a bit of mess due to dynamic ip, nats, etc.

[Jay Beavers]

On the off chance that everything is working, my hg repository is now served via http://hikingforum.homedns.org:8000.  Hopefully this doesn't mean you can all now read my bank account information :-)

I'm submitting changesets 17 & 18 for review.

[Noah Hart]

Miguel

Do you have experience with your mono projects about how best to add
multiple development paths here?

Noah

[Miguel de Icaza]

Hello Noah,

Do you have experience with your mono projects about how best to add multiple development paths here?

Many of our developers keep private trees and forks while they develop a feature, but at the end of the day, we need to merge all of it in the central repository.

The central repository is where the official release comes from, where the testing is done, where the packaging is done, so there is always a strong incentive to get the patches back up.

Miguel.

[Phil Haack]

We follow the same process with Subtext, though we use private branches rather than private repositories since we’re still using positively archaic centralized source control (Subversion), not like you cutting edge distributed source control people. ;) The concept and process is the same though.

 

In general, we avoid doing any half-ass checkins to the main repository. We also have a continuous integration server which is publicly available: http://build.subtextproject.com/ccnet/ViewFarmReport.aspx

 

If you go there right now, you’ll even see that our trunk is broken due to a 32bit/64bit issue I’m in the middle of fixing. Bad Phil! Bad! J I think a CI server is an absolute necessity.

 

Phil