Kazutoshi Satoda wrote:
> >> The fix is filtering out DeltaV properties from allprop request.
> >> This is also a way to get conformance with DeltaV. But this breaks
> >> backward compatibility because old(and existing) ra_dav code is
> >> expecting that an allprop response contains DAV:version-name and
> >> DAV:creator-displayname as the last committed revision and author
> >> respectively. I'm not sure but suspecting ra_serf has same expectation.
> >> ...
> >
> > So shouldn't be the first step to fix the svn client code so that
> > explicitly asks for the properties its interested in? That would allow
> > full RFC3253 compliance in two versions from now...
>
> Thank you for your reply, but I think it shouldn't.(I'm sorry but
> I'm not sure what the "two versions from now" means. I read it as
> "1.3.x and 1.4.x")
>
> If we fix the client first, and fix the server in the full conforming
> way(filtering out all DeltaV properties) assuming that the wrong
> expectation was fixed, then 1.3.0(or older) client won't work with
> the fixed server. So I think "full RFC3253 compliance" can not be
That's why the client should be fixed first, so that the server can be
fixed (in a fully compliant way) when all supported client versions are
known to work.
> allowed without breaking old clients. That is why I proposed a
> compromising. In the compromising, fixing the client is not required.
> It can be said as another(probably minor) issue.
>
> Am I missing something?
Yes. If you don't fix the client, you can't make the server fully
compliant at a later point of time (right?).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 20 18:32:23 2006