Daniel Rall wrote:
> On Mon, 12 Feb 2007, John Peacock wrote:
>
>> Blair Zajac wrote:
>>> With mod_dav_svn, I guess we can get the client version string and use
>>> that? Would the easy way be to reject commits at the Apache level and
>>> parse the client's name?
>>>
>>> But what about file:/// or svn:// access?
>
> Was this in response to my recent addition to the func spec?
> http://subversion.tigris.org/merge-tracking/func-spec.html#migration-and-interoperability
>
> I tend to agree...
Yes, prompted by that commit.
>> file:/// access is, pretty much by default, not something that you would want to
>> allow any sort of public access. svn:// is only slightly better, from a
>> security standpoint. I don't think it is *too* much of a loss if we only
>> provided a way to block back-rev'd client access under Apache.
>
> We could do some type of client capabilities detection, and pass that
> on to the hook scripts via a new parameter or environment variable.
> Client capabilities aren't easily detectable in a mod_dav_svn
> environment, however...
I presume there are new APIs that the svn HTTP client is using to send
to the server to update the metadata? Or this is just a property only
change?
Could we not have the client always make a call to some new API that
would indicate to mod_dav_svn that even if there's no merge metadata to
send, that the client would have sent it if there was info to send?
The server could have a bit checked when it saw this call, indicating
that the client is merge metadata aware.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 13 03:13:34 2007