<?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/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule">

<channel>
	<title>yergler.net &#187; subversion</title>
	<atom:link href="http://yergler.net/blog/tag/subversion/feed/" rel="self" type="application/rss+xml" />
	<link>http://yergler.net</link>
	<description>Because eventually I&#039;ll be right. Theoretically.</description>
	<lastBuildDate>Tue, 31 Jan 2012 05:43:29 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Upgrading WordPress</title>
		<link>http://yergler.net/blog/2008/08/21/upgrading-wordpress/</link>
		<comments>http://yergler.net/blog/2008/08/21/upgrading-wordpress/#comments</comments>
		<pubDate>Fri, 22 Aug 2008 00:33:19 +0000</pubDate>
		<dc:creator>Nathan Yergler</dc:creator>
				<category><![CDATA[geek]]></category>
		<category><![CDATA[git]]></category>
		<category><![CDATA[subversion]]></category>
		<category><![CDATA[upgrade]]></category>
		<category><![CDATA[version control]]></category>
		<category><![CDATA[wordpres]]></category>

		<guid isPermaLink="false">http://yergler.net/blog/?p=630</guid>
		<description><![CDATA[WordPress 2.6.1 is out. Reading feeds on my flight from IND to PHX this afternoon I ran across the WordPress Automatic Upgrade Plugin (shouldn&#8217;t that be the Automattic?). Nice, but I&#8217;d like to plug my approach to managing WordPress upgrades, which I think is even easier, assuming you&#8217;re OK with minimal command-line interaction. First, install [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://wordpress.org/development/2008/08/wordpress-261/">WordPress 2.6.1</a> is out.  Reading feeds on my flight from IND to PHX this afternoon I ran across the <a href="http://techie-buzz.com/wordpress-plugins/wordpress-automatic-upgrade-12-release.html">WordPress Automatic Upgrade Plugin</a> (shouldn&#8217;t that be the <em>Automattic</em>?).  Nice, but I&#8217;d like to plug my approach to managing WordPress upgrades, which I think is even easier, assuming you&#8217;re OK with minimal command-line interaction.</p>
<p>First, install WordPress from a Subversion checkout; do:<br />
<code><br />
$ svn co http://svn.automattic.com/wordpress/tags/2.6/<br />
</code><br />
instead of downloading the .zip or .tar.gz file.  Configure as directed.</p>
<p>Then, when a new version is available, log into your webhost and run:<br />
<code><br />
$ svn switch http://svn.automattic.com/wordpress/tags/2.6.1/<br />
</code><br />
from your install directory.</p>
<p>Done.</p>
<p>Note that you can also do something similar (but an order of magnitude more complex, at least for my brain) using <a href="http://en.wikipedia.org/wiki/Git_(software)">git</a> and <a href="http://www.kernel.org/pub/software/scm/git/docs/git-svn.html">git-svn</a> if you want to version your local settings as well.  Perhaps one day <a href="http://asheesh.org">Asheesh</a> or I will get that written up.</p>
]]></content:encoded>
			<wfw:commentRss>http://yergler.net/blog/2008/08/21/upgrading-wordpress/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Sane Merging in SVN</title>
		<link>http://yergler.net/blog/2007/11/06/sane-merging-in-svn/</link>
		<comments>http://yergler.net/blog/2007/11/06/sane-merging-in-svn/#comments</comments>
		<pubDate>Tue, 06 Nov 2007 18:32:25 +0000</pubDate>
		<dc:creator>Nathan Yergler</dc:creator>
				<category><![CDATA[development]]></category>
		<category><![CDATA[branch]]></category>
		<category><![CDATA[subversion]]></category>

		<guid isPermaLink="false">http://yergler.net/blog/2007/11/06/sane-merging-in-svn/</guid>
		<description><![CDATA[We use &#8220;Subversion&#8221;:http://subversion.tigris.org for &#8220;version control&#8221;:http://en.wikipedia.org/wiki/Revision_control at &#8220;work&#8221;:http://creativecommons.org. We try to version control everything: code, content, graphics, site configuration. &#8220;Everything&#8221;:http://cctools.svn.sourceforge.net. This does wonders for our sanity, but we can do more. Recently (n < 6 months)) we&#8217;ve started doing something we should have done from Day 1: develop in one tree, deploy in another. In [...]]]></description>
			<content:encoded><![CDATA[<p>We use &#8220;Subversion&#8221;:http://subversion.tigris.org for &#8220;version control&#8221;:http://en.wikipedia.org/wiki/Revision_control at &#8220;work&#8221;:http://creativecommons.org.  We try to version control everything: code, content, graphics, site configuration.  &#8220;Everything&#8221;:http://cctools.svn.sourceforge.net.  This does wonders for our sanity, but we can do more.  Recently (<code>n < 6</code> months)</code>) we&#8217;ve started doing something we should have done from Day 1: develop in one tree, deploy in another.  In our case we&#8217;re developing in the <code>trunk</code>, and there&#8217;s a long-lived branch cleverly named <code>production</code>.  This is great, with one little problem: cherry-picking revisions to merge in Subversion is a pain in the ass.</p>
<p>Last week I was looking at the &#8220;upcoming features&#8221;:http://subversion.tigris.org/roadmap.html in Subversion 1.5.  &#8220;Asheesh&#8221;:http://asheesh.org/note/ had pointed out the &#8220;merge tracking&#8221;:http://subversion.tigris.org/merge-tracking/ feature, which sounded lovely.  And it probably will be.  The thing I discovered, though, is that you can get it today in the form of &#8220;svnmerge&#8221;:http://www.orcaware.com/svn/wiki/Svnmerge.py.</p>
<p><code>svnmerge</code> allows you to track what revisions you&#8217;ve merged from a branch (or trunk), block certain revisions (features you might not want to deploy just yet), and performs the merges for you when that time arrives (including generating a nice commit message containing all the log messages you&#8217;re merging; handy).  I spent an hour yesterday and an hour today getting the merges recorded for the packages I&#8217;m currently working on, and it already feels better.  No more wondering if I remembered to merge something; just <code>svnmerge avail</code> and see if anything shows up.</p>
<p>Sure, it&#8217;ll be great to get this feature into the core application (and an interactive mode ala &#8220;darcs&#8221;:http://darcs.net would be slick, too), but to paraphrase Scarlett O&#8217;Hara, &#8220;with god as my witness, I will never <code>svn merge</code> again&#8221;.</p>
]]></content:encoded>
			<wfw:commentRss>http://yergler.net/blog/2007/11/06/sane-merging-in-svn/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

