<?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"
	>
<channel>
	<title>Comments on: Subversion Repository Reorg</title>
	<atom:link href="http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/feed/" rel="self" type="application/rss+xml" />
	<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/</link>
	<description>If I could put reflection under this header, I would.</description>
	<pubDate>Wed, 20 Aug 2008 20:28:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: blake</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-393</link>
		<dc:creator>blake</dc:creator>
		<pubDate>Wed, 01 Feb 2006 03:17:22 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-393</guid>
		<description>Ugh - I haven't found a good way to reorganize repositories quickly and easily (or to import an existing repository along with all its history into a new repository). For me, even small reorgs require LOTS of individual file moves. Blech.</description>
		<content:encoded><![CDATA[<p>Ugh - I haven&#8217;t found a good way to reorganize repositories quickly and easily (or to import an existing repository along with all its history into a new repository). For me, even small reorgs require LOTS of individual file moves. Blech.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay C. James</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-392</link>
		<dc:creator>Jay C. James</dc:creator>
		<pubDate>Mon, 30 Jan 2006 18:51:33 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-392</guid>
		<description>We are inheriting a previous installation of Subversion with all its trees and branches and so forth. Did you happen to create any utilities to assist you with importing your existing framework? Just curious, because it looks as if this could be potentially time consuming if we have to manually import hundreds of disparate development branches into a new SVN installation! :)
Any tips or hints or pointers to sites involved with batching any of this stuff?</description>
		<content:encoded><![CDATA[<p>We are inheriting a previous installation of Subversion with all its trees and branches and so forth. Did you happen to create any utilities to assist you with importing your existing framework? Just curious, because it looks as if this could be potentially time consuming if we have to manually import hundreds of disparate development branches into a new SVN installation! <img src='http://blakeseely.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
Any tips or hints or pointers to sites involved with batching any of this stuff?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Jalkut</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-346</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Thu, 22 Dec 2005 06:09:54 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-346</guid>
		<description>Interesting. Well hopefully I'm safe for now since I'm keeping my repositories local. If your hosting company doesn't support subversion, I think Dreamhost does and is pretty cheap.</description>
		<content:encoded><![CDATA[<p>Interesting. Well hopefully I&#8217;m safe for now since I&#8217;m keeping my repositories local. If your hosting company doesn&#8217;t support subversion, I think Dreamhost does and is pretty cheap.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blake</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-345</link>
		<dc:creator>blake</dc:creator>
		<pubDate>Thu, 22 Dec 2005 01:07:22 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-345</guid>
		<description>Unfortunately, I am using fsfs. :( *But*, I have kind of a funky setup besides that. I have my repository hosted on the same hosting account as this site (with a different subdomain), and they weren't really set up for Subversion. I'm accessing it using svn+ssh and had to do some specific setup so that I could access Subversion that way. Every now and then, I will get some errors if multiple processes are trying to update the repository from the same machine at the same time. This tended to happen when Xcode was querying the repository at the same time I was using SvnX to make some updates - forgetting that Xcode 2.2 could now access my svn+ssh URLs correctly.
I don't know if that was the cause of my problems, but problems nonetheless. I don't really know how to inspect any repository structures to see exactly what the damage is - but it's on my list of to-do's to try to take a look sometime.</description>
		<content:encoded><![CDATA[<p>Unfortunately, I am using fsfs. <img src='http://blakeseely.com/blog/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /> *But*, I have kind of a funky setup besides that. I have my repository hosted on the same hosting account as this site (with a different subdomain), and they weren&#8217;t really set up for Subversion. I&#8217;m accessing it using svn+ssh and had to do some specific setup so that I could access Subversion that way. Every now and then, I will get some errors if multiple processes are trying to update the repository from the same machine at the same time. This tended to happen when Xcode was querying the repository at the same time I was using SvnX to make some updates - forgetting that Xcode 2.2 could now access my svn+ssh URLs correctly.<br />
I don&#8217;t know if that was the cause of my problems, but problems nonetheless. I don&#8217;t really know how to inspect any repository structures to see exactly what the damage is - but it&#8217;s on my list of to-do&#8217;s to try to take a look sometime.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Jalkut</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-344</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Thu, 22 Dec 2005 00:40:42 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-344</guid>
		<description>It has to be asked  whether you're using the "fsfs" or "Berkeley DB" back-end for your repository storage. The DB backend is notorious for going corrupt, and I learned this the hard way myself :(  Releases of subversion over the past several months (longer?) have defaulted to the "fsfs" format for this reason.

If you're getting corruption from the fsfs format then I guess I will add a little bit of paranoia to my setup. I have been error free since &lt;a href="http://www.red-sweater.com/blog/?p=22" rel="nofollow"&gt;changing formats&lt;/a&gt; a while back.</description>
		<content:encoded><![CDATA[<p>It has to be asked  whether you&#8217;re using the &#8220;fsfs&#8221; or &#8220;Berkeley DB&#8221; back-end for your repository storage. The DB backend is notorious for going corrupt, and I learned this the hard way myself <img src='http://blakeseely.com/blog/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' />  Releases of subversion over the past several months (longer?) have defaulted to the &#8220;fsfs&#8221; format for this reason.</p>
<p>If you&#8217;re getting corruption from the fsfs format then I guess I will add a little bit of paranoia to my setup. I have been error free since <a href="http://www.red-sweater.com/blog/?p=22" rel="nofollow">changing formats</a> a while back.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blake</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-343</link>
		<dc:creator>blake</dc:creator>
		<pubDate>Wed, 21 Dec 2005 18:27:01 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-343</guid>
		<description>Oh, and yes, a few of my projects will remain separate - one is totally unrelated to any cocoa work that I've been doing, and one was just a proof of concept for a friend - similar to client code.</description>
		<content:encoded><![CDATA[<p>Oh, and yes, a few of my projects will remain separate - one is totally unrelated to any cocoa work that I&#8217;ve been doing, and one was just a proof of concept for a friend - similar to client code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blake</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-342</link>
		<dc:creator>blake</dc:creator>
		<pubDate>Wed, 21 Dec 2005 18:23:51 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-342</guid>
		<description>That's a pretty good point - basically, what I really want is a combination of the two options I described. I want the trunks separate, and possibly the branches, but I really want the tags to be repository-wide. Very good point.

And some sort of meta-svn browser is an excellent idea. I'll have to think about that. I'm sure there's some tough problems to solve in a program like that.</description>
		<content:encoded><![CDATA[<p>That&#8217;s a pretty good point - basically, what I really want is a combination of the two options I described. I want the trunks separate, and possibly the branches, but I really want the tags to be repository-wide. Very good point.</p>
<p>And some sort of meta-svn browser is an excellent idea. I&#8217;ll have to think about that. I&#8217;m sure there&#8217;s some tough problems to solve in a program like that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Jalkut</title>
		<link>http://blakeseely.com/blog/archives/2005/12/21/subversion-repository-reog/#comment-341</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Wed, 21 Dec 2005 17:24:48 +0000</pubDate>
		<guid isPermaLink="false">http://blakeseely.com/blog/?p=51#comment-341</guid>
		<description>I currently have my projects in separate repositories. I think I had the same feeling you did about the sense of separation, but am now also facing problems with wanting to "link" between some projects.

I'm not quite convinced to go the single repository route, yet. In particular I think projects for clients will always go in separate repositories. It makes me feel good to know that I have something concrete and separate that I can use to generate a source drop for a client or whatever.

Given your current switch to a single repository, I would suggest keeping the tags and branches at the highest level. Doing otherwise you end up with a similar problem to the separate repositories issue: you will have to manage multiple tags for a single release. Suppose you have MyProduct 1.0 and it depends on sources from MyProduct and MyLibrary.  Now to tag the release you'll have to tag both MyProduct and MyLibrary. Putting a tags folder at the top allows you to easily tag the whole thing.

Of course, you could keep both and just have a "globaltags" folder at the top level.

I haven't thought it out too well, but I like the idea of some kind of thin module on top of subversion that would automatically handle "multi-repository projects".  This would eliminate a lot of the decisionmaking about whether to group as single or multiple repositories. It would be great to be able to say "this project is comprised of the following SVN repositories." Then when you wanted to tag or checkout you could just refer to the "meta repository" that knew about all the required repositories.

I haven't even looked to see if something like that might exist out there. I think that would be a pretty nice, flexible add on.</description>
		<content:encoded><![CDATA[<p>I currently have my projects in separate repositories. I think I had the same feeling you did about the sense of separation, but am now also facing problems with wanting to &#8220;link&#8221; between some projects.</p>
<p>I&#8217;m not quite convinced to go the single repository route, yet. In particular I think projects for clients will always go in separate repositories. It makes me feel good to know that I have something concrete and separate that I can use to generate a source drop for a client or whatever.</p>
<p>Given your current switch to a single repository, I would suggest keeping the tags and branches at the highest level. Doing otherwise you end up with a similar problem to the separate repositories issue: you will have to manage multiple tags for a single release. Suppose you have MyProduct 1.0 and it depends on sources from MyProduct and MyLibrary.  Now to tag the release you&#8217;ll have to tag both MyProduct and MyLibrary. Putting a tags folder at the top allows you to easily tag the whole thing.</p>
<p>Of course, you could keep both and just have a &#8220;globaltags&#8221; folder at the top level.</p>
<p>I haven&#8217;t thought it out too well, but I like the idea of some kind of thin module on top of subversion that would automatically handle &#8220;multi-repository projects&#8221;.  This would eliminate a lot of the decisionmaking about whether to group as single or multiple repositories. It would be great to be able to say &#8220;this project is comprised of the following SVN repositories.&#8221; Then when you wanted to tag or checkout you could just refer to the &#8220;meta repository&#8221; that knew about all the required repositories.</p>
<p>I haven&#8217;t even looked to see if something like that might exist out there. I think that would be a pretty nice, flexible add on.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
