(Replying to everyone in one go to reduce the spam)
On Wed, Feb 14, 2007 at 01:00:39PM -0800, Blair Zajac wrote:
> Malcolm Rowe wrote:
> >file:/// clients, by definition, can do anything to the repository,
> >including corrupting it beyond all recognition. Adding any kind of
> >security to ra_local is basically not going to work - the client is
> >responsible for enforcing it.
>
> I don't see anywhere that we treat file:/// by definition any different
> than the other protocols.
>
Well, ra_local repositories don't support any form of authz, for one.
You're trusting that the client will be a good client and run the
hooks, set the right author name, etc - an ra_local client using the
Subversion API (even through the bindings) can basically do anything.
> I don't see it hard having the svn client provide an environmental
> variable that the pre-commit script can look for the existence of.
>
It's not difficult inasmuch as it doesn't really buy you anything for
ra_local clients: it only solves the specific problem of a well-behaved
client using pre-1.5 libraries doing a merge and not recording history.
It doesn't, for example, solve the problem of the same user doing a
merge via diff/patch to his local wc and committing using a 1.5 client.
I dunno, I just think it's a problem better solved through policy that
via technical means.
[Oh, technically, we would have to work out how to pass the client
library version number over ra_svn, but that's just a SMOP.]
On Wed, Feb 14, 2007 at 01:54:24PM -0800, Blair Zajac wrote:
> Much easier to exclude all clients < 1.5 and have a company policy that
> any clients that come online need to be >= 1.5 than to distinguish
> between types of merges.
>
Those two are orthogonal. Do you _really_ need the technical part if
you've already established a non-technical policy?
On Wed, Feb 14, 2007 at 01:41:00PM -0800, Daniel Rall wrote:
> Indeed. I share Blair's concerns here. I know this will be a
> complaint from my customer base.
>
Dan, in your case, you serve everything over ra_dav, right? If so, you
already have the useragent string available in every request (something
like "SVN/1.4.0 (r21228) neon/0.25.5"), and so you can just install a
frontend filter to match on the UA (something I suspect that Apache can
do quite easily).
On Wed, Feb 14, 2007 at 10:47:14PM +0100, Erik Huelsmann wrote:
> When we introduced locking, didn't we do a little trick to ensure we
> were using only the right (locking) clients/servers to access a
> repository?
No, we didn't. We said 'don't do that', which IMO was the right answer.
Pre-1.2 clients just don't respect locks, but we don't lock out the
repository either.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Thu Feb 15 10:18:25 2007