[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bundles Re: SVN, .SVN, and other meta-data directories

From: Jonathan S. Shapiro <shap_at_eros-os.org>
Date: 2000-08-27 19:03:42 CEST

> How about XML? It's just 'binish' enough to keep newbies from mucking it,
> but is still parsable.

I'm fond of XML, but at the risk of irking people yet again, let me share my
experience with it from another project.

We've been looking at cutting the EROS documentation over to XML for quite
some time. There are many reasons to prefer XML to the current format, not
least of which is the fact that it would let us easily generate documents in
multiple formats. Standards like XSLT are far enough along that the
document generation should be pretty straightforward if we can get a XSLT
transformer that works.

The only thing that has prevented us from doing this is the absence of an
open source XSLT processor that (a) meets the standards and (b) is NOT
written in Java. In the absence of an independent specificatoin and given
the current Sun licensing policies, I don't anticipate porting Java to EROS
any time soon, and I don't want to build something into the tool chain that
may not be self-hostable.

Things have probably changed since the last time I looked, and it's in my
queue to look again. I know that the Xalan-C project is underway, but the
last time I tried it no progress was made.

My point is that in practice XML seems to introduce a hidden dependency on
Java. This may be perfectly okay for your application, but it's a dependency
that should be accepted with eyes open.

If anyone has had success with a non-Java XSLT transformer, I would
appreciate a *private* note.

Finally, I think you are underestimating the editability of XML.

> I'm presently using a system from Synchronicity (EDAcentric) that uses
> 'turd' directories, but is not at all upset if the data is removed -- it
> just recreates it from the server data.

If this fits in the SVN design, it seems to provide the best of both worlds.
The problem I see is that the server must now remember what has been checked
out. If I always go to the same server that should be okay. If servers
someday become distributed it gets a bit hairier.

shap
Received on Sat Oct 21 14:36:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.