Does mod_dav_svn expose the FS API for "open <this> txn and edit it"? If so, how does it ensure that the txn it modifies hasn't been passed to a pre-commit hook already?
[ asking in the hope that someone knows the answer; if no one answers and I can't find it myself I'll follow up on dev@ ] On Monday, November 28, 2011 8:36 AM, "Daniel Shahaf" <d...@daniel.shahaf.name> wrote: > I haven't read the thread but I'd like to clarify one thing: a pre- > commit hook sees the transaction (ie, candidate revision) as it will > exist once committed. It sees exactly what is deleted and what is > modified. And it can accept or reject it on that basis. > > On Monday, November 28, 2011 11:47 AM, "Jerryleen S" > <jerrylee...@prdcinfotech.com> wrote: > > Dear Niko, Cooke, > > > > Thanks for the suggestions, will try putting forward this ideas to > > management. Hoping for the best. > > > > Thanks and Regards, > > > > Jerryleen S > > > > Project Coordinator, PRDC > > > > > > > > -----Original Message----- > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > > Sent: Friday, November 25, 2011 9:18 PM > > To: Cooke, Mark > > Cc: Jerryleen S; users@subversion.apache.org; channaveeraswamy > > Subject: Re: Queries about SVN (Security related) > > > > On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark <mark.co...@siemens.com> wrote: > > > [Please reply in-line, it makes it easier to see the full context...] > > > > >> > Dear Sir, > > >> > > > >> > We are in the process of selecting SVN system in our company, > > >> > could you please clarify following points. > > >> > > > >> > 1. Restricting branching activity based on roles specified. > > >> > That is denying branch functionality to users based on > > >> > their roles. > > >> > 2. Denying delete/add folder to certain users, it is not just > > >> > r or r/w. if user has r/w access but shouldn't have delete or > > >> > add access, only modify commit should be accessible. > > >> > > >> This functionality is not "baked in". It might well be > > >> possible to do with a pre-commit hook but you (your admin > > >> team) would need to write and maintain the script. > > >> Personally I have not tried to do such things. > > > > Amen. Pre-commit scripting is extremely powerful and flexible, because > > it supports whatever a scripting language can do. But let's be clear. > > If they have "modify" access, they have "delete" access, at least with > > the scripting and authorization structures I've seen. > > > > "Create" access is a bit different: there are setups that allow > > creating tags, for example, but not deleting them. > > > > You also want to think very hard about what kind of access you > > provide, and what kind of layout you use. Apache access allows access > > control through normal Apache configurations, which can be quite > > sophisticated, but presents the old (and much lamented by me) problem > > that the UNIX and Linux Subversion clients store their passwords in > > clear text, by default, for http:// or https:// access. It's why I > > insiste on svn+ssh access, and that has different tools for > > controlling access based on the svnserve configuration. > > > > Workflow will also matter tomake it usable. Will people work in one > > large repository with lots of branches and distinct projects, each > > with their own branches and trunks and tags? This is common, and may > > be easier to manage, but means one authorization and access setup to > > manage and to screw up. If it's chaning all the time, it's easy to cut > > off *everyone's* access with one typo, and there aren't currently > > GUI's or sophisticated editing tools for managing this, so use caution > > before getting too cute. > > > > > > >> > > 3. Is it possible host repos in 2 different physical locations? > > >> > > > >> > What do you mean by host? There is built-in support for > > >> > providing read-only mirrors (also as write-through proxies) > > >> > but if you want multiple 'master' repositories then you need > > >> > to look to WanDISCO's proprietry MultiSite extension. > > >> > > > >> I meant in Collabnet admin GUI we can give location of only > > >> one data location, i.e., if we want to place repos in more > > >> than one machine or physical location, is it possible. > > >> > > > Do you mean separate repositories? That is down to how you configure > > > apache. I have not used the Collabnet admin GUI having decided at the > > > start that I wanted to understand what was going on. You can easily > > > declare multiple SVNParentPath locations (I do this for hosting separate > > > groups of projects) within the one apache config. However, AFAIK you > > > need the data files on storage "local" to the server (networked storage > > > does not seem to be recommended). I use a virtualised windoze server box > > > with virtual local disk space but we have modest storage requirements so > > > far. > > > > There's also the more sophisticated tools of WanDisco's commercial > > grade "multi-home" setup, designed to keep multiple repositories > > synchronized and available for failover behavior. Interesting stuff > > that I've not had the money and personal requirement for, but it might > > serve for this. > > > > > > >> > 4. How to delete folders or file permanently. > > >> > > >> I assume you mean "remove completely from all history"? > > >> Ignoring all the arguments about if a source control product > > >> should even allow this, it is only currently possible by > > >> 'dump', 'dumpfilter' and 'reload'ing the whole repository. > > >> It is a feature on the roadmap > > >> (http://subversion.apache.org/roadmap.html) called > > >> 'obliterate' but not soon. > > > > Yes, "obliterate". Its absence is a long-standing problem: Once > > someone stores an inappropriate and bulky DVD image, or a file with > > confidential information in it, it's an extremely awkward and fragile > > and manual process to remove it. The easiest way is usually to > > transfer the data to a new repository with the old data excluded, and > > switch everyone to use the new repository. This can cause real > > problems with ongoing work, but it works. > > > > Note that the idea that a source control should *never* eliminate all > > traces of its history is understandable. It used to be too easy to > > completely screw up a CVS repository with a casual deletion of a > > particular file, and Subversion is sometimes referred to as "CVS done > > right", so the historical resistance to such a feature is > > understandable. It's very dangerous and could delete exactly the > > change history you need badly to figure out when something got screwed > > up and by whom, so it should be used cautiously. > > ****************************************************************************************************************** > > Please consider the environment before printing this email. Do it only if > > it is absolutely necessary. > > > > DISCLAIMER: > > The contents of this email including attachment(s), if any, are intended > > for the exclusive use of the addressee(s) and > > may contain proprietary, confidential or privileged information. If you > > have received this mail in error, please notify the > > sender immediately and destroy all copies of this message and any > > attachment(s).Computer viruses or other malware > > can be transmitted by email. Therefore, please check this email and any > > attachment(s) for the presence of viruses, malware, > > etc. The PRDC accepts no liability whatsoever for any damage - whether > > direct or consequential - caused by any virus, malware, > > etc. transmitted by this email. > > ****************************************************************************************************************** > > ****************************************************************************************************************** > > Please consider the environment before printing this email. Do it only if > > it is absolutely necessary. > > > > DISCLAIMER: > > The contents of this email including attachment(s), if any, are intended > > for the exclusive use of the addressee(s) and > > may contain proprietary, confidential or privileged information. If you > > have received this mail in error, please notify the > > sender immediately and destroy all copies of this message and any > > attachment(s).Computer viruses or other malware > > can be transmitted by email. Therefore, please check this email and any > > attachment(s) for the presence of viruses, malware, > > etc. The PRDC accepts no liability whatsoever for any damage - whether > > direct or consequential - caused by any virus, malware, > > etc. transmitted by this email. > > ****************************************************************************************************************** > > >
