Lee Iverson wrote:
>
> One of the design requirements (both from bootstrapping and
> sociological points of view) is that the development OHS/DKR we are
> developing interoperate with current open-source development
> "best-practices". One of those best-practices is CVS/CVSWeb.
>
Yes, I am in total agreement that this is desirable. I'm just not
convinced it's practical, or even feasible.
> Now when we combine this observation with the reality that it is
> unlikely that software development will be engaged in using XML-tagged
> source code we are left with the strategy of using some transcoding
> layer on top of the source to allow for unambiguous referential
> hyperlinking into sources (and that is the context in which I
> mentioned SDS).
>
In the Extende list at Sourceforge, I have argued that XML-tagged
source code can provide powerful benefits for those who use it.
(Not, however, using the SDS format, as useful as it is for other
purposes.)
What I see in that scenario is that *others* aren't using XML-based
code, so there is a necessity to translate back and forth from one
to the other. Transcoding would work for that, as well. The bottom
line in that environment is that the XML-based editor can make
changes that are reflected in the plain source, and vice versa.
However, there are several tricky aspects to that translation. In
fact, the majority of the complexity in the system comes from doing
so. And even then, the system isn't taking into account links
and such.
> So, the reality of the situation can be summarized thus:
>
> 1) Source code with CVS is already archived and
> version-controlled.
> 2) A CVSWeb (or similar) interface provides a Web-enabled view of
> the full version-controlled hierarchy.
> 3) SDS (or similar markup system) provides the ability to
> unambiguously refer hyperlink *into* source code and
> follow sorce cross-references.
>
> It would seem to me to be wasteful to OHS-ize the sources every time a
> revision is made simply in order to be able to make references in
> discussions or documents. Moreover, it would be counterproductive to
> require developers to "buy-in" to the OHS environment, a possible
> consequence of requiring ingestion, in order to participate in
> development discussions.
>
Yes, the desirability is given. But will it work? I think I see
a way in which it is possible, but it requires translating.
Here's what I see:
* Plain source doc is translated into OHS format
* OHS format may well consist of pointers into the plain doc
* A person changes the plain source doc and commits it to CVS
* On next access of the OHS doc, the system recognizes that
the source doc has changed.
* The system then interrogates the CVS repository to identify
the changes, and adjusts the OHS pointer-doc
* Note that the OHS pointer doc *must* remain persistent, so that
the links made to it from other docs remain intact. This is
a performance requirement, actually. The consistency could be
retained with transcoding, but only if the entire CVS history
is transcoded each time, so that the node IDs remain intact.
As another step:
* When a person modifies the OHS version, the source document is
automatically modified and CVS-commited.
------------------------------------------------------------------------
Old school buds here:
http://click.egroups.com/1/4057/4/_/444287/_/958507116/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Tue May 16 2000 - 13:06:28 PDT