Let me point out that trying to use an sccs for this has been tried, and you may want to think twice. When vasa and I originally conceived DP50 it was our (or at least my) intention to use subversion or git as the text repository. The further we got into it, the less desirable it seemed to become - for a number of reasons. I&#39;m not saying it can&#39;t be made to work, and work successfully. But it&#39;s not a slam dunk.<div>
<br></div><div>For one, maintaining text is not the same as maintaining source code. And in particular,the work flow for software development is not the same as ours. And if there&#39;s any guiding principle behind sccs, it&#39;s to support the depth and breadth of software development.</div>
<div><br></div><div>We found we could get along fine for a long time storing simple versions of text in a structured directory design that was easier to use and monitor. And we could always get to our text in another obvious way.</div>
<div><br></div><div>We ended up spending a lot of time just figuring out the sccs APIs (which again are designed to support software development) and they aren&#39;t simple or really very flexible. We had to mostly adapt our conceptual models to theirs - there isn&#39;t much room to fiddle with theirs.</div>
<div><br></div><div>Sccs transactions can be very slow.</div><div><br></div><div>I realize we had different needs - here we&#39;re talking about at least mostly-completed projects, not page-or-less components. But I don&#39;t see how we easily avoid at least some extension in the proofing direction if we really want to do continuous semi-open-access improvement of texts. I think it requires administrative resources we&#39;ll never have to do it any other way.</div>
<div><br></div><div>Could we just call it &quot;the repository&quot; or something for a while? I think we should maybe spend more time coming at it from the user&#39;s direction and refining some requirements before we make technology choices.</div>
<div><br></div><div>And in that direction I think automating the build process to be more dependency-sensitive might pay off more in the short run. Maybe it&#39;s there and I don&#39;t know it, but I haven&#39;t heard much of that flavor to the discussion so far.</div>