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

Re: merge tracking: rejecting commits from svn clients < 1.5

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-02-13 03:13:08 CET

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

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.


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

This is an archived mail posted to the Subversion Dev mailing list.