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

Re: XML parse error: Not well-formed (Not neon-0.24.3/svn bug)

From: <kfogel_at_collab.net>
Date: 2003-10-09 16:55:48 CEST

"C. Michael Pilato" <cmpilato@collab.net> writes:
> It's a problem with DAV because they chose XML (and all the
> limitations that come with it) for their marshaling system.

And we chose DAV for a transport layer.

(Glass houses... stones... you get the idea :-) ).

> Note that we probably don't have this problem over ra-svn (just like
> countless other data transport problems we have in ra-dav but not in
> ra-svn). Why? Because Greg Hudson has his head on straight and
> decided that it was more sensible to design his own protocol with no
> obvious technical limitations than to select the trendiest-yet-limited
> protocol du jour.
> I'm not saying that it's bad to to have technical limitations. Who
> gives a rip if C/Java won't let you have spaces in your symbols?
> Symbols aren't the level at which users of software typically deal.
> It doesn't matter that a piece of recipe software can't use a variable
> named "Name of Recipe", but you better believe that people would hit
> the roof if their recipe names couldn't have spaces.

All granted.

As far as fixing the problem goes, I think Julian Foad's suggestion is

> For now, if this can't be fixed easily, to prevent users getting
> into a mess, should we make "svn propset" check that the property
> name is composed from a safe set of characters, and politely
> refuse if not?

It means that all RA layers suffer from the limitations of one RA
layer, but it's only a tiny bit of suffering (no one's gonna die
because they can't have spaces in their property names). +1 on
committing this, if that's what you were planning to do, Julian.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 9 17:31:01 2003

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.