On Fri, Feb 02, 2001 at 06:43:08AM -0600, Ben Collins-Sussman wrote:
> Sam TH <sam@uchicago.edu> writes:
>
> > 1) Should the DTD cover the postfix delta format? I ask because it
> > isn't really possible, not without adding another root element outside
> > tree-delta?
>
> I believe this DTD already exists. Check the mail archive:
>
> http://subversion.tigris.org/subversion-dev/6/msg00171.html
>
> Perhaps it's not part of the source tree though... we could fix this.
Well, it isn't in the source tree. Has the spec for the XML format
changed at all since September?
>
> >
> > 2) (Random and pedantic) Does SVN_ERR_MALFORMED_XML represent
> > non-well-formed XML (as the name indicates) or invalid XML (as the
> > comment immediately preceding indicates)? It's unlikely that
> > subversion will actually validate the XML, since it's using expat,
> > which has no plans to become a validating parser.
>
> Right, expat only checks for well-formed XML. Validation isn't
> possible with expat, and we don't care much.
>
Patch for the comment. (How can I make ediff respect .cvsrc?)
Index: svn_error.h
===================================================================
RCS file: /cvs/subversion/subversion/include/svn_error.h,v
retrieving revision 1.66
diff -u -c -r1.66 svn_error.h
cvs server: conflicting specifications of output style
*** svn_error.h 2001/01/25 20:30:52 1.66
--- svn_error.h 2001/02/02 12:54:57
***************
*** 44,50 ****
SVN_ERR_MALFORMED_FILE,
SVN_ERR_INCOMPLETE_DATA,
! /* The xml delta we got was not valid. */
SVN_ERR_MALFORMED_XML,
/* A working copy "descent" crawl came up empty */
--- 44,50 ----
SVN_ERR_MALFORMED_FILE,
SVN_ERR_INCOMPLETE_DATA,
! /* The xml delta we got was not well formed. */
SVN_ERR_MALFORMED_XML,
/* A working copy "descent" crawl came up empty */
>
> > 3) Speaking of expat, since the subversion project began, expat has
> > undergone a number of radical changes. It is now autoconfiscated, and
> > libtoolized. It builds a shared library, and does other nice things.
> > Would people be interested in changing to the newer version? (Yeah, I
> > am volunteering for the work.)
>
> Um... our XML needs are pretty lightweight. If we switch to the
> "real" expat, I see a big disadvantage: we now depend on *another*
> external package (it's already annoying enough that we have to
> manually fetch APR and Neon to build). As it is, it's convenient to
> have expat-lite as a permanent part of our tree, and it's perfectly
> sufficient for what we're doing.
>
Well, I think that having the newer version of expat as part of the
tree would be an excellent idea. It hasn't changed much about
November of last year, and should be quite stable.
> That said, what are the pros of upgrading? I can't think of any.
>
Well, there are a few.
1) Subversion could link against a version of expat already on the
system (shared versions of expat are available for Debian already)
2) There's an interface to set your own memory handler for expat, so
we might get it to use APR stuff (NB: I've never actually looked at
it).
3) It has a bunch of new features merged since James Clark stopped
maintaining it (mostly developed for Perl expat). Mostly these
involve handling parts of the file in different ways, or handling
different parts of the file (that expat didn't previously).
4) I'm not entirely sure when the version of expat that is in the
Subversion tree is, but if it's before expat 1.1, then all the stuff
relating to namespaces is missing too. Unfortunately, since James
Clark provides no information about the different versions at all,
it's hard to tell exactly what's different.
5) If the expat people make any other changes Subversion might care
about, they would be mergable.
6) The expat people are making sure it's portable to various
platforms.
Well, 1 is really the biggest one here. And, for reference, if you
remove the sample applications, the newer expat is about 1500 lines of
source longer than expat-lite (11000 vs 9500).
sam th
sam@uchicago.edu
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:21 2006