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

Alan Barrett wrote:
> No, svn+ssh:// is not morally equivalent to file:// access. It does
> not require a local account to be associated with the ssh key.

I didn't suggest that a *different* local account was required for each
ssh key, but rather that *a* local account was required. svn+ssh
executes svnserve as some local user account which requires read/write
access to the repository (which is why multiple local accounts is a pain
to configure properly). That svnserve process then communicates via the
tunnel with the local (to the user) svn client. svn+ssh is also not
able to be used for anonymous read-only access (since you have to add
the ssh key before you can get any access). You can run svn:// access
in read-only mode, however

However, as sussman has pointed out, the svnserve protocol already has
client capabilities negotiation. It seems likely that both svnserve and
mod_dav_svn could be taught to block back-rev'd client access without
much difficulty. The question then becomes how to write that interface...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org