Re: REPOST: Using Apache Limit directive with SVN
From: David Weintraub <qazwart_at_gmail.com>
Date: Mon, 24 Nov 2008 11:59:01 -0500
On Mon, Nov 24, 2008 at 12:46 AM, Tarek Nabil <Tarek.Nabil_at_dubaiworld.ae> wrote:
You have to rollback the entire repository including other projects in
It seems simple enough to limit the rollback to a specific project,
svn cp -r1234 svn://localhost/project/branches/1.3
This will restore the branch, and not affect anything else in the
As I said before, you can create a pre-commit hook that prevents
BTW, I structure my repositories by putting the branches, tags, and
The disadvantage is creating this structure for each project, and the
-- David Weintraub qazwart_at_gmail.com On Mon, Nov 24, 2008 at 12:46 AM, Tarek Nabil <Tarek.Nabil_at_dubaiworld.ae> wrote: > I'd like just to tell about our experience with allowing delete for > everyone. Disasters happen when people do mistakes while renaming or > replacing branches. Usually, the results are catastrophic to the extent > that in order to undo the changes, one has to rollback the whole > repository to the revision number before such a change, effectively > rolling back everyone else's work during this period. > > This leads me to another question; does the SVN team recommend one > repository per application/module or one repository for all the modules? > I see a trade off here between reducing the administrative overhead and > reducing the impact of such incidents on unrelated modules. > > Appreciate your feedback. > > Best regards, > Tarek Nabil > > > -----Original Message----- > From: David Weintraub [mailto:qazwart_at_gmail.com] > Sent: Sunday, November 23, 2008 6:14 PM > To: Tarek Nabil > Cc: users_at_subversion.tigris.org > Subject: Re: REPOST: Using Apache Limit directive with SVN > > 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 >> >> > ********************************************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.orgReceived on 2008-11-24 17:59:28 CET |
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.