<?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: Three months in the Sub</title>
	<atom:link href="http://gojko.net/2007/04/17/three-months-in-the-sub/feed/" rel="self" type="application/rss+xml" />
	<link>http://gojko.net/2007/04/17/three-months-in-the-sub/</link>
	<description>Building software that matters</description>
	<lastBuildDate>Fri, 12 Mar 2010 16:28:45 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Arild Fines</title>
		<link>http://gojko.net/2007/04/17/three-months-in-the-sub/comment-page-1/#comment-7350</link>
		<dc:creator>Arild Fines</dc:creator>
		<pubDate>Fri, 20 Apr 2007 15:40:07 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/2007/04/17/three-months-in-the-sub/#comment-7350</guid>
		<description>gojko: AnkhSVN does not &quot;silently die&quot; when you attempt a rename of an added file; there is a message written to the output pane. For some reason, Ankh/VS doesn&#039;t always switch to this pane when this message is written, so I can understand that it can be overlooked. 

I have some plans now to support this scenario by having Ankh automatically revert the file before a rename if its status is Added (as long as it doesn&#039;t have copy history, a revert in this case would be bad...), and then re-adding it after the rename is completed.

Jeff: the problem with deleting and readding a web reference is most likely a Subversion limitation. Once the reference is deleted, the WC will have a pending delete for that file. Until that delete is committed or reverted, any attempt to add a file with the same name will fail.</description>
		<content:encoded><![CDATA[<p>gojko: AnkhSVN does not &#8220;silently die&#8221; when you attempt a rename of an added file; there is a message written to the output pane. For some reason, Ankh/VS doesn&#8217;t always switch to this pane when this message is written, so I can understand that it can be overlooked. </p>
<p>I have some plans now to support this scenario by having Ankh automatically revert the file before a rename if its status is Added (as long as it doesn&#8217;t have copy history, a revert in this case would be bad&#8230;), and then re-adding it after the rename is completed.</p>
<p>Jeff: the problem with deleting and readding a web reference is most likely a Subversion limitation. Once the reference is deleted, the WC will have a pending delete for that file. Until that delete is committed or reverted, any attempt to add a file with the same name will fail.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: greggman</title>
		<link>http://gojko.net/2007/04/17/three-months-in-the-sub/comment-page-1/#comment-7321</link>
		<dc:creator>greggman</dc:creator>
		<pubDate>Thu, 19 Apr 2007 23:43:34 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/2007/04/17/three-months-in-the-sub/#comment-7321</guid>
		<description>I used subversion on my last project. I mostly enjoyed it but there are two things.  

#1) No auto merging of branches. Supposedly this will be fixed in v1.5 so this issue will go away.

#2) Speed.  I make video games and we need to version control assets (textures, 3d models, animations). Toward the end of our project it became painfully clear that Subversion is not up to that task. I have to assume the people creating it are managing typical software projects of at most a few hundred or a thousand source files. Once you get into multi GIGS of game assets though, of which gigs are updated daily it bogs down so bad that it became clear switching to Perforce, even at $700 per seat, was far cheaper than wasting 1-2 hours a day per person waiting for Subversion. 

Clearly this will only effect teams that manage assets with their asset management system. I can only hope at some point the subversion team will make speed a bigger priority.</description>
		<content:encoded><![CDATA[<p>I used subversion on my last project. I mostly enjoyed it but there are two things.  </p>
<p>#1) No auto merging of branches. Supposedly this will be fixed in v1.5 so this issue will go away.</p>
<p>#2) Speed.  I make video games and we need to version control assets (textures, 3d models, animations). Toward the end of our project it became painfully clear that Subversion is not up to that task. I have to assume the people creating it are managing typical software projects of at most a few hundred or a thousand source files. Once you get into multi GIGS of game assets though, of which gigs are updated daily it bogs down so bad that it became clear switching to Perforce, even at $700 per seat, was far cheaper than wasting 1-2 hours a day per person waiting for Subversion. </p>
<p>Clearly this will only effect teams that manage assets with their asset management system. I can only hope at some point the subversion team will make speed a bigger priority.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stefan</title>
		<link>http://gojko.net/2007/04/17/three-months-in-the-sub/comment-page-1/#comment-7260</link>
		<dc:creator>Stefan</dc:creator>
		<pubDate>Wed, 18 Apr 2007 05:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/2007/04/17/three-months-in-the-sub/#comment-7260</guid>
		<description>&#039;repairing&#039; a wrong commit is easy with TortoiseSVN:
* open the log dialog for the folder in question
* select the revision which was wrongfully committed
* right-click
* choose &quot;revert changes from this revision&quot;
--&gt; the changes you committed will be reverse merged into your working copy (i.e., it will look as if you checked out the previous revision and copied all files on your working copy, overwriting the changes you committed wrongfully).
* commit again</description>
		<content:encoded><![CDATA[<p>&#8216;repairing&#8217; a wrong commit is easy with TortoiseSVN:<br />
* open the log dialog for the folder in question<br />
* select the revision which was wrongfully committed<br />
* right-click<br />
* choose &#8220;revert changes from this revision&#8221;<br />
&#8211;&gt; the changes you committed will be reverse merged into your working copy (i.e., it will look as if you checked out the previous revision and copied all files on your working copy, overwriting the changes you committed wrongfully).<br />
* commit again</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Staddon</title>
		<link>http://gojko.net/2007/04/17/three-months-in-the-sub/comment-page-1/#comment-7242</link>
		<dc:creator>Jeff Staddon</dc:creator>
		<pubDate>Tue, 17 Apr 2007 17:26:45 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/2007/04/17/three-months-in-the-sub/#comment-7242</guid>
		<description>Great post.  In my use of Subversion the only problem I&#039;ve run into so far is in Visual studio when I delete and re-create a web reference.  For some reason it doesn&#039;t always cleanly handle the re-creation.  Not sure why/exactly what triggers the problem.  On the whole though it&#039;s been great.  It does a great job of supporting multiple people working in the same .Net project which is something that Visual Source Safe didn&#039;t handle well for us in the past.</description>
		<content:encoded><![CDATA[<p>Great post.  In my use of Subversion the only problem I&#8217;ve run into so far is in Visual studio when I delete and re-create a web reference.  For some reason it doesn&#8217;t always cleanly handle the re-creation.  Not sure why/exactly what triggers the problem.  On the whole though it&#8217;s been great.  It does a great job of supporting multiple people working in the same .Net project which is something that Visual Source Safe didn&#8217;t handle well for us in the past.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic page generated in 0.297 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2010-03-17 06:40:01 -->
