<?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: Antipattern  Repository</title>
	<atom:link href="http://www.longacre-scm.com/blog/index.php/2006/02/antipattern-repository/feed" rel="self" type="application/rss+xml" />
	<link>http://www.longacre-scm.com/blog/index.php/2006/02/antipattern-repository</link>
	<description>Opinions on CM, software development, and process automation from Longacre.</description>
	<lastBuildDate>Fri, 30 Jul 2010 19:08:51 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Austin Hastings</title>
		<link>http://www.longacre-scm.com/blog/index.php/2006/02/antipattern-repository/comment-page-1#comment-6</link>
		<dc:creator>Austin Hastings</dc:creator>
		<pubDate>Thu, 09 Mar 2006 11:53:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.longacre-inc.com/blog/index.php/2006/02/antipattern-repository#comment-6</guid>
		<description>&lt;p&gt;Think for a moment about what you just said: you want all your stuff using a common repository.&lt;/p&gt;

&lt;p&gt;Thing is, all your stuff doesn&#039;t even share a common approach to storage. Blogs and Plogs and Forums are storing their info in databases, source code goes in files, AutoCAD is writing single giant entities (either a megafile or a custom database, your cal).&lt;/p&gt;

&lt;p&gt;I think what you really want, and this is probably worth money, is a common repository interface. And I don&#039;t mean WebDAV.&lt;/p&gt;

&lt;p&gt;I think it&#039;s some common mechanism for specifying release/branch/time configspecs that gets shared across everywhere.&lt;/p&gt;

&lt;p&gt;Part of that almost certainly translates into something implemented at the OS level, for performance. But the rest of it I think has to be worked in to applications. Are you familiar with OS9&#039;s backup mechanism? A virtual directory of datestamps that can be traversed to find a version of a file at some arbitrary timepoint.&lt;/p&gt;

&lt;p&gt;That mechanism, or something like it, probably needs to be generalized.&lt;/p&gt;

&lt;p&gt;The right place to start, I think, is with a journaling filesystem. After all, that&#039;s how the big storage is implemented, so it&#039;s certainly where implementation will have to go. Beyond that, there&#039;s some kind of mixin technology that permits identifying branches.&lt;/p&gt;

&lt;p&gt;I think I&#039;ll post on this, if you don&#039;t beat me to it. Maybe a CMJ article...&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Think for a moment about what you just said: you want all your stuff using a common repository.</p>
<p>Thing is, all your stuff doesn&#8217;t even share a common approach to storage. Blogs and Plogs and Forums are storing their info in databases, source code goes in files, AutoCAD is writing single giant entities (either a megafile or a custom database, your cal).</p>
<p>I think what you really want, and this is probably worth money, is a common repository interface. And I don&#8217;t mean WebDAV.</p>
<p>I think it&#8217;s some common mechanism for specifying release/branch/time configspecs that gets shared across everywhere.</p>
<p>Part of that almost certainly translates into something implemented at the OS level, for performance. But the rest of it I think has to be worked in to applications. Are you familiar with OS9&#8217;s backup mechanism? A virtual directory of datestamps that can be traversed to find a version of a file at some arbitrary timepoint.</p>
<p>That mechanism, or something like it, probably needs to be generalized.</p>
<p>The right place to start, I think, is with a journaling filesystem. After all, that&#8217;s how the big storage is implemented, so it&#8217;s certainly where implementation will have to go. Beyond that, there&#8217;s some kind of mixin technology that permits identifying branches.</p>
<p>I think I&#8217;ll post on this, if you don&#8217;t beat me to it. Maybe a CMJ article&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Appleton</title>
		<link>http://www.longacre-scm.com/blog/index.php/2006/02/antipattern-repository/comment-page-1#comment-4</link>
		<dc:creator>Brad Appleton</dc:creator>
		<pubDate>Thu, 02 Mar 2006 08:36:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.longacre-inc.com/blog/index.php/2006/02/antipattern-repository#comment-4</guid>
		<description>&lt;p&gt;Hmmn - I agree with the distributed development &quot;next big thing&quot; in CM. And a few years ago I thought that the Arch &amp; Bitkeeper way of treating each workspace as a first class repository, with patch-based updates (sort of) was going to be the wave of the future. Not clear yet whether I was wrong on that, or just off by five years in my timing.&lt;/p&gt;

&lt;p&gt;But I still want &quot;one repository&quot; for all my lifecycle artifacts. Or, rather, I should really say I want to use the &lt;em&gt;same&lt;/em&gt; repository for all of them. Im fine with having distributed repositories, or even the Arch/Bitkeeper model of workspace as a repository. My quarrel is with having to integrate the tools (and corresponding repositories) for by source-code management, requirements management, test management, document management, and models/model management. I want the nice spiffy interface and features of each of those tools, but I sure do wish they could all operate on the same repository. That would be a full lifecycle CMDB.&lt;/p&gt;

&lt;p&gt;But I agree that the distributed &quot;thing&quot; is going to be needed too - and with the increased focus on collaboration and innovation over geographical boundaries, it&#039;s a lot easier on branching to use the Arch/Bitkeeper style.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hmmn &#8211; I agree with the distributed development &#8220;next big thing&#8221; in CM. And a few years ago I thought that the Arch &amp; Bitkeeper way of treating each workspace as a first class repository, with patch-based updates (sort of) was going to be the wave of the future. Not clear yet whether I was wrong on that, or just off by five years in my timing.</p>
<p>But I still want &#8220;one repository&#8221; for all my lifecycle artifacts. Or, rather, I should really say I want to use the <em>same</em> repository for all of them. Im fine with having distributed repositories, or even the Arch/Bitkeeper model of workspace as a repository. My quarrel is with having to integrate the tools (and corresponding repositories) for by source-code management, requirements management, test management, document management, and models/model management. I want the nice spiffy interface and features of each of those tools, but I sure do wish they could all operate on the same repository. That would be a full lifecycle CMDB.</p>
<p>But I agree that the distributed &#8220;thing&#8221; is going to be needed too &#8211; and with the increased focus on collaboration and innovation over geographical boundaries, it&#8217;s a lot easier on branching to use the Arch/Bitkeeper style.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
