>> 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
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?
---------------------------------------------------------------------
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:26:10 2006