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

Re: mod_dav_svn backward compatibility broken?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-03-05 17:22:41 CET

mark benedetto king <mbk@boredom.org> writes:

> On Tue, Mar 04, 2003 at 02:49:49PM -0800, Greg Stein wrote:
> >
> > 1) stop returning NE_XML_DECLINE. return NE_XML_VALID and jettison the
> > unknown element in our start_handler. (this shifts the "ignore unknown
> > elements" from the validator to the element handler)
> >
> > 3) beat Joe into adding NE_XML_IGNORE for elements which are "valid" but
> > can simply be ignored [if no other handler wants them]. we would then
> > need a mandated upgrade of Neon.
> >
> > My favorite is option (1) for short term (the 0.19 release), and option (3)
> > for the long term plan.
> >
> > In all cases, this also implies that the server should stop sending the UUID
> > for now, until we get "enough" clients with the flexible handling. If we
> > really need the server to send the UUID, then we can *temporarily* put the
> > thing into the server headers; that works fine for ra_dav, but is not a good
> > long-term WebDAV-y solution.
> >
>
> Why don't we do this:
>
> a.) immediately stop sending UUIDs on update. I *think* the liveprop
> entries are okay. Are they?
> b.) in the same atomic change, start sending an "X-SVN-Repository-UUID: "
> header, and modify ra_dav to handle this.
> c.) do (1)
> d.) do (3)
> e.) wait until most clients are updated. I think, at a minimum, this means
> binary packages available for most OSen + one more month. There's really
> no forcing function on this.
> f.) revert (a)
>
> Thoughts?

+1. Amen, Brother.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 5 15:25:12 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.