<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>David Lynch &#187; svn</title>
	<atom:link href="http://davidlynch.org/blog/tag/svn/feed/" rel="self" type="application/rss+xml" />
	<link>http://davidlynch.org/blog</link>
	<description>has a blog</description>
	<lastBuildDate>Fri, 18 Jun 2010 07:37:01 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>svn synonym</title>
		<link>http://davidlynch.org/blog/2007/12/svn-synonym/</link>
		<comments>http://davidlynch.org/blog/2007/12/svn-synonym/#comments</comments>
		<pubDate>Tue, 11 Dec 2007 17:07:50 +0000</pubDate>
		<dc:creator>David</dc:creator>
				<category><![CDATA[programming]]></category>
		<category><![CDATA[svn]]></category>
		<category><![CDATA[version control]]></category>

		<guid isPermaLink="false">http://davidlynch.org/blog/2007/12/svn-synonym/</guid>
		<description><![CDATA[I&#8217;d like to take a moment to (a) completely alienate my audience, and (b) ruin my credibility. I will do this by discussing the semantics of a particular operation of the Subversion version control system, and explaining how poorly I initially understood it. It took me a while to realize how svn merge should be [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;d like to take a moment to (a) completely alienate my audience, and (b) ruin my credibility.  I will do this by discussing the semantics of a particular operation of the 
<a  href="http://subversion.tigris.org/">Subversion</a> version control system, and explaining how poorly I initially understood it.</p>
<p>It took me a while to realize how <code>svn merge</code> should be used.  My intuitive sense of the usage of the command diverged significantly from its actual use.</p>
<p>When I think of it as &#8220;merge&#8221; the syntax that intuitively appears is <code>svn merge [source] [target]</code>, with the intent of merging &#8220;source&#8221; into &#8220;target&#8221;.</p>
<p>This led to my attempting to merge from branch HEAD to trunk HEAD, and be puzzled at the lack of effect.</p>
<p>I find that everything fits together if I think of <code>svn merge</code> as a synonym for <code>svn repeat</code>.  You&#8217;re asking for the changes between two revisions to be applied to the current working copy.</p>
<p>Thus <code>svn merge branches/coolfeature trunk</code> doesn&#8217;t do anything <em>because it doesn&#8217;t describe any changes</em>.</p>
<p>What&#8217;s required is <code>svn merge branches/coolfeature@73 branches/coolfeature@HEAD</code>, which takes the changes made to the coolfeature branch between revision 73 and the latest revision, and applies them to the working copy you&#8217;re currently in.</p>
<p>(It&#8217;s much shorter to write this as: <code>svn merge -r 73:HEAD branches/coolfeature</code>)</p>
<p>The awkward bit is finding out when you should start merging from (the &#8220;73&#8243; in my example).  To do this you have to read the logs and find either the revision where you created the branch or the last revision you merged from, whichever is more recent.</p>
<p>All this should become irrelevant shortly, though.  Subversion 1.5 (
<a  href="http://blog.red-bean.com/sussman/?p=79">according to an aside in this developer blog post</a>) will automatically track much merge metadata so the requirement to specify revision ranges of changes to merge should be eliminated in the common case.  I look forward to it.</p>
]]></content:encoded>
			<wfw:commentRss>http://davidlynch.org/blog/2007/12/svn-synonym/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
