I didn't reply because I am not sure how Apache requests are mapped to
Subversion, and I was hoping someone more familiar with this issue
would.
However, we shouldn't really care how Subversion/Apache transactions
are mapped. Subversion has a nice exposed API, and well documented
actions. We shouldn't be trying to get around them because they could
change from revision to revision or maybe act differently depending
upon each system.
Subversion uses Apache as its transport mechanism, and may depend upon
certain transactions that are not clearly mapped to you. These have to
do with transaction processing or how the Subversion repository is
actually setup. If there is any sort of mapping between Subversion
command and the Apache transaction, it is mainly incidental
(especially considering that Subversion doesn't have to use Apache).
There are already well documented mechanisms to do what you want
without poking into the Subversion/Apache transaction internals.
You can handle basic authorization via Apache: Whether someone has
read/write access or doesn't have read/write access to a particular
part of the repository.
To get beyond merely setting read/write access to a particular
Subversion directory or repository,
use a pre-commit hook. There are several around, or you could write
your own. Most hooks allow you to setup read-only, read-write, and
add-only permissions. (Add-only is used for tags where you want users
to be able to create a tag, but not modify it). Most don't have a
no-delete setting, but that shouldn't be too difficult to include. The
problem with a no-delete setting is that this also hampers moves and
renames. Preventing someone from deleting will prevent them from being
able to name or delete a file.
I would recommend that you simply use email notifications for watching
particular files instead of preventing deletes. Remember this is a
revision control system, so you can always restore changes people make
-- including restoring deleted files.
I hope this helps.
> Dear all,
>
> Could anyone advise on whether SVN commands map directly to HTTP method
> names?
>
> As mentioned in my email below, I've noticed that when committing an
> "ADD" for example, SVN is issuing a "DELETE" request to Apache.
>
> Further - to my surprise - this "DELETE" is being issued in a different
> transaction since I notice that although I get an error (due to lack of
> permission), still the transaction is committed on the repository.
>
> Best regards,
> Tarek Nabil
>
> -----Original Message-----
> From: Tarek Nabil
> Sent: Wednesday, November 19, 2008 1:25 PM
> To: users_at_subversion.tigris.org
> Subject: RE: Using Apache Limit directive with SVN
>
> Thanks Larry for your response.
>
> As I mentioned, I'm aware that the same functionality can be provided by
> hook scripts, but I was more inclined to use Apache.
>
> Best regards,
> Tarek Nabil
>
>
>
>
> -----Original Message-----
> From: Larry Shatzer, Jr. [mailto:larrys_at_gmail.com]
> Sent: Tuesday, November 18, 2008 7:26 PM
> To: Tarek Nabil
> Cc: users_at_subversion.tigris.org
> Subject: Re: Using Apache Limit directive with SVN
>
> On Tue, Nov 18, 2008 at 5:20 AM, Tarek Nabil <Tarek.Nabil_at_dubaiworld.ae>
> wrote:
>> Hi,
>>
>>
>>
>> I'm aware that this is not the recommended approach by the SVN team,
> but we
>> have a requirement to restrict the users who are able to DELETE files
> from
>> the repository.
>>
>>
>
> Have you looked at svnperms.py?
>
> http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/svnperms.conf.e
> xample
> http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/svnperms.py
>
> -- Larry
>
>
> Hi,
>
>
>
> I'm aware that this is not the recommended approach by the SVN team, but
> we have a requirement to restrict the users who are able to DELETE files
> from the repository.
>
>
>
> Since authz_svn_module only provides two options, i.e. "r" or "rw", I
> have resorted to another approach which uses the "Limit" directives of
> Apache.
>
>
>
> I'm using: SVN for win32 v.1.5.4 and Apache 2.2.10 running on Windows XP
> (should be moved to Windows Server 2003 if the approach is verified).
>
>
>
> I've done the necessary configuration and it is working fine from the
> Apache side, but I hit another problem; it seems that the requests made
> by the SVN client (whether command line or Tortoise) do not exactly
> match the HTTP requests expected.
>
>
>
> For example, I've done the configuration so that only a certain user is
> allowed to delete. The problem is when I modify a file and attempt to
> commit, Apache is still requiring authentication. The reason is,
> although I have not deleted any file, still there's a DELETE request
> being sent. I get the following message if I do not enter the username
> and password:
>
>
>
> svn: DELETE of
> '/svn/testrepo/!svn/act/a7a8bc40-1a67-774c-87e9-a24bdb88a911':
> authorization failed
>
>
>
> My guess is that this file is internally used by SVN, but that totally
> invalidates the whole approach because I can not assume that deleting a
> file issues an HTTP DELETE request and adding a file issues an HTTP PUT
> request.
>
>
>
> I'd appreciate if someone could advise on whether this is a valid
> approach or not. I'm already aware that the same can be done using
> hooks, but I preferred an out-of-the-box approach.
>
>
>
> The configuration I did is as follows:
>
>
>
> #SVN repositories
>
> <Location /svn>
>
> DAV svn
>
> SVNParentPath D:\svn-repos
>
> AuthType Basic
>
> AuthName "Test Repository"
>
> AuthUserFile "D:\Programs\Apache2.2\conf\svnpasswd"
>
> <Limit DELETE>
>
> Require user tnabil
>
> </Limit>
>
> </Location>
>
>
>
>
>
> Best regards,
>
> Tarek Nabil
> ********************************************DISCLAIMER********************************************
> This email and any files transmitted with it are confidential and contain privileged or copyright
> information. If you are not the intended recipient you must not copy, distribute or use this email
> or the information contained in it for any purpose other than to notify us of the receipt thereof.
> If you have received this message in error, please notify the sender immediately, and delete this
> email from your system.
>
> Please note that e-mails are susceptible to change.The sender shall not be liable for the improper
> or incomplete transmission of the information contained in this communication,nor for any delay in
> its receipt or damage to your system.The sender does not guarantee that this material is free from
> viruses or any other defects although due care has been taken to minimise the risk.
> **************************************************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-23 15:15:46 CET