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

RE: http MERGE authorization problem

From: Sander Striker <striker_at_apache.org>
Date: 2004-04-07 17:40:22 CEST

> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Wednesday, April 07, 2004 5:32 PM

> The problem here is step 5: libsvn_client is anchoring the commit on
> the common parent of source and target. It's actually *required* to do
> this for 'svn mv', but our code is currently optimized to do the same
> thing for 'svn cp', since those commands often share a lot of code.
>
> Rather than look for anchor-target workarounds, I'm wondering if we
> can't solve the problem by teaching mod_authz_svn to simply ignore the
> URI argument to MERGE.
>
> In theory (according to RFC), the URI to MERGE is a parent-dir of some
> kind, which identifies potential merge targets. But if you read the
> very bottom section of our notes/webdav-general-summary (and our
> comments at the top of mod_dav_svn/merge.c), you can see that our own
> implementation of MERGE is very simple. I believe that the URI passed
> to MERGE is completely ignored: we only care about the activity
> "source" passed in the headers and request body, and automatically merge
> *all* targets in the activity.
>
> Therefore, I wonder if we just shouldn't make mod_authz_svn ignore the
> URI argument to MERGE. In my opinion, MERGE and MKACTIVITY should both
> be allowed as long as the user has *some* write access somewhere in the
> repository. The URI doesn't need to be checked.

I'm fine with that. I can fix up mod_dav_svn over the w-e. That is,
if the URI argument is indeed senseless. This comes with some issues
wrt anon-access, but I'll bring that up when I hit those during coding...

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 17:41:06 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.