<?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: Shelving Subversion</title>
	<atom:link href="http://mikemason.ca/blog/2005/03/shelving-subversion/feed/" rel="self" type="application/rss+xml" />
	<link>http://mikemason.ca/blog/2005/03/shelving-subversion/</link>
	<description>agile thinking</description>
	<lastBuildDate>Mon, 28 Dec 2009 21:52:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Chris Rathjen</title>
		<link>http://mikemason.ca/blog/2005/03/shelving-subversion/comment-page-1/#comment-2</link>
		<dc:creator>Chris Rathjen</dc:creator>
		<pubDate>Wed, 02 Jan 2008 13:25:37 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=11#comment-2</guid>
		<description>I&#039;m glad to see a nice clean example of this.

Shelving vs. Branching (or creating a new view/workspace/enlistment) is definitely a tradeoff. Shelves are intended to be temporary creations and satisify a particular set of scenarios. If you need rich control over a set of potential changes, or need a lot of &#039;bake time&#039; before committing them, a private branch is definitely the way to go.

Having said that, there&#039;s times where the shelve feature can speed up part of your process. We find it particularly useful internally for code reviews (just email around the unshelve link and anyone can do a complete code review, buddy build, buddy test, etc.), and for late stages in the cycle where every checkin receives higher scrutiny. The shelveset becomes &#039;the proposed change&#039;, but is a more tangible artifact than the difference between a private branch and the source branch: It&#039;s easy for ANY party to review, not just other devs and testers, and it makes building and testing *just that change* a straightforward process.

I imagine you could create those scenarios in a Subversion UI without much (if any) changes to the core feature set - it builds on logic that already exists in commands like branch, merge, and new workspace.</description>
		<content:encoded><![CDATA[<p>I&#8217;m glad to see a nice clean example of this.</p>
<p>Shelving vs. Branching (or creating a new view/workspace/enlistment) is definitely a tradeoff. Shelves are intended to be temporary creations and satisify a particular set of scenarios. If you need rich control over a set of potential changes, or need a lot of &#8216;bake time&#8217; before committing them, a private branch is definitely the way to go.</p>
<p>Having said that, there&#8217;s times where the shelve feature can speed up part of your process. We find it particularly useful internally for code reviews (just email around the unshelve link and anyone can do a complete code review, buddy build, buddy test, etc.), and for late stages in the cycle where every checkin receives higher scrutiny. The shelveset becomes &#8216;the proposed change&#8217;, but is a more tangible artifact than the difference between a private branch and the source branch: It&#8217;s easy for ANY party to review, not just other devs and testers, and it makes building and testing *just that change* a straightforward process.</p>
<p>I imagine you could create those scenarios in a Subversion UI without much (if any) changes to the core feature set &#8211; it builds on logic that already exists in commands like branch, merge, and new workspace.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
