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

Re: certain property names cause non-wf XML responses

From: <kfogel_at_collab.net>
Date: 2004-10-20 14:51:32 CEST

Ben Reser <ben@reser.org> writes:
> On Mon, Oct 18, 2004 at 03:30:03PM -0500, kfogel@collab.net wrote:
> > If we discourage them from using colons, I think they're experiencing
> > pain (all "svk:" users, for example?).
> They are? Where? Since I added the workaround nobody has had any
> issues with coloned properties within the context of using our libs.
> Which includes SVK. The only way anyone would be having any problems is
> if they're mixing using SVK and generic DAV clients. Which I suspect is
> pertty rare. If it wasn't clkao would have switched to something like
> svk.foo by now.

Ah, what I meant was, if we discourage them from using colons, then
*if they take our advice*, they'll experience pain. Right now they're
not experiencing, pain. But that's because they get to use colons.

> Anyway you've posted an alternate solution I've come up with on Issue
> #1971. So this thread is pretty much dead at this point.


I think your custom-report solution also lessens the urgency of #1971,
because there aren't any important compatibility stages. We can add
the feature to client and server simultaneously, and each would retain
the ability to work the old way when faced with an older interlocutor.

The only thing with compatibility implications is for the server to
stop sending DAV-incompatible props over DAV. But as there's no
corresponding client change to that, it's simply a one-time thing that
we do at 2.0 (but not before, of course, because it would break 1.x
client compatibility).

Sanity check: does the above make sense?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 16:42:38 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.