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

Re: svn log causes XML parse error (internal error)

From: Ben Reser <ben_at_reser.org>
Date: 2004-07-23 20:21:31 CEST

On Fri, Jul 23, 2004 at 10:14:08AM -0500, kfogel@collab.net wrote:
> Hey, now :-). Neglecting to specify the encoding scheme doesn't make
> it a drive-by suggestion. Obviously we *can* encode data safely,
> using whatever minimal set of characters we're allowed as long as
> there are at least two distinct characters available.
> I'm not denying the ugliness of the solution, any more than of the
> problem that motivates it. But there's a lot of room between
> "ready-to-publish RFC spec" and "drive-by suggestion". If we insisted
> that every proposal made on this list be a complete and
> ready-to-implement specification, we'd never have gotten a lot of the
> features and bugfixes we have today. Leave some room for discussion,
> please.
> You can disagree with a proposal on technical or aesthetic grounds,
> without libeling it as "drive-by".

Well all of this has somewhat come up before and encoding it was
suggested then. Everyone just assumed that it could be done with URI
encoding. Leaving out how you plan on encoding it was a pretty
important thing to leave out becuase the method we'd probably most
likely want to use won't work.

Considering that this was all discussed on the colon issue, it seemed
rather driveby to come along and say "Let's just encode it." When
past discussions have shown it's really not that easy.

> Yeah, but wait a sec.
> You just proposed, and tossed, three solutions based on namespaces.
> None of them were the solution I proposed, which is also based on a
> namespace, but as it's *Subversion*'s namespace, it maintains
> compatibility (as far as we know) -- which is exactly why I used it.
> There are an infinite number of non-working solutions for any problem.
> Proposing three of them here, only to shoot them down, doesn't add
> anything to the discussion. There's surely some Latin name for this
> rhetorical technique :-), but I don't know it. All I know is, it
> doesn't mean anything. The number of non-working solutions thought of
> has *no relevance* to the solubility of a problem. Once you know they
> don't work, there's just no reason to bring them up again.

Sure I had plenty of reason to bring them out again. Because by leaving
off the encoding scheme in your suggestion it seemed as though you
weren't aware of them. Bringing them out again saved everyone the time
of thinking them up again and then trying to implement them, because we
found your solution inelegent.

Ben Reser <ben@reser.org>
"A nation that forgets its past is doomed to repeat it."
- Sir Winston Churchill
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 23 20:21:48 2004

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.