<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The committer model in practice</title>
	<atom:link href="http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/feed/" rel="self" type="application/rss+xml" />
	<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/</link>
	<description>freelance software developer</description>
	<lastBuildDate>Tue, 03 Aug 2010 19:04:01 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: warren</title>
		<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/comment-page-1/#comment-47</link>
		<dc:creator>warren</dc:creator>
		<pubDate>Tue, 28 Mar 2006 11:51:19 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-47</guid>
		<description>One of the things we found useful with subversion was to use the post-commit hook that will email you whenever a checkin occurs (well in practice, it emails the developer mailing list) This is a great avenue for impromptu code review when you can look over the code that&#039;s been checked in and discuss any issues with the rest of the list.

They&#039;re also useful to some extent in monitoring the rest of the team&#039;s progress. I&#039;m wary however of letting management folks get these emails, they tend to try and derive naive metrics from them, eg 

&quot;how come X has committed 100 lines of code when Y has only committed 1 line today&quot; even though person Y may have been slaving away all day to reproduce an obscure bug and just checked in a critical fix for it.</description>
		<content:encoded><![CDATA[<p>One of the things we found useful with subversion was to use the post-commit hook that will email you whenever a checkin occurs (well in practice, it emails the developer mailing list) This is a great avenue for impromptu code review when you can look over the code that&#8217;s been checked in and discuss any issues with the rest of the list.</p>
<p>They&#8217;re also useful to some extent in monitoring the rest of the team&#8217;s progress. I&#8217;m wary however of letting management folks get these emails, they tend to try and derive naive metrics from them, eg </p>
<p>&#8220;how come X has committed 100 lines of code when Y has only committed 1 line today&#8221; even though person Y may have been slaving away all day to reproduce an obscure bug and just checked in a critical fix for it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Cohen</title>
		<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/comment-page-1/#comment-46</link>
		<dc:creator>Mark Cohen</dc:creator>
		<pubDate>Tue, 28 Mar 2006 10:59:08 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-46</guid>
		<description>I totally agree with your sentiments and observations.  We recently migrated to Subversion and now work with a trunk and a release branch, and by evolution ended up at almost the exact working rules you outlined in the points 1 to 3 above.  We face some problems with skill level, cut-and-paste programming and oddly enough trust similar to what you outline above too.</description>
		<content:encoded><![CDATA[<p>I totally agree with your sentiments and observations.  We recently migrated to Subversion and now work with a trunk and a release branch, and by evolution ended up at almost the exact working rules you outlined in the points 1 to 3 above.  We face some problems with skill level, cut-and-paste programming and oddly enough trust similar to what you outline above too.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
