Hello, I posted a question on the community page (see link below) and markphip replied. https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=550254
The post is shown below Issue 1 The access rule contain: [aliases] idan = ignace.danneels [groups] sol_dev = &bwal,&idan the I would prevent that user to access a specific folder by putting [CBD_Test_Environment:/] &idan = rw [CBD_Test_Environment:/trunk/20_Software/Sources/CBD] &idan= to prevent idan for accessing that subfolder The main issue is that rules tend to change (software development is a living thing). Currently we are using Tortoise client for subversion (I'm using subversion Edge version 4.0.1) Assume the 2nd rule did not exist at first. Then when idan checks out the repository, he obtains the subfolder on his workstation. Now I implement the 2nd rule, because we notice that only a limited set of persons should have access to it, and idan is not one of them. If I perform an update on the project (even with the changed rules), the CBD folder remains on the workstation. If I delete the folder (locally), and perform an update, the subfolder is restored. What I would like to obtain: because the new rule indicates access to the subfolder is no longer granted, it should be removed locally. Now I can only way I can obtain this by deleting the entire project/repository locally and checking out the repository again. Issue 2 Use of wildcards: I'm working in a group of software developers, in which one team should have access to a subfolder, while another part of the team should not. I noticed that only rules with correct case sensitive names are accepted. The issue here is that while developing software, we often create branches (for releases, for tests, ...), and the same rules should apply. I just learned from the answer that SVN does not support wildcards I tried to create a rule that would exclude the CBD folder from all branches/trunk/tags in the repository as follows: [CBD_Test_Environment:/*/CBD] &idan= Because the CBD folder also contains xml files, which are useless for one specific group, I also wanted to change the rule as follows: [CBD_Test_Environment:/*/CBD/*.c] &idan=rw [CBD_Test_Environment:/*/CBD/*.h] &idan=rw Hoping the * would mean any path in the repository. Unfortunately, this does not appear to work. Although the access rule appears to be accepted by subversion edge (there is no error when entering the rules above), I have found no documentation on the web indicating the use of wildcards in access rules. As I'm a big fan of regular expressions, I also tested if the 2 latter rules could be merged into 1 as follows [CBD_Test_Environment:/*/CBD/*\.(c|h)] &idan=rw Also here the rule is accepted. Issue 3 Assume the CBD folder has 20 subfolders and I would want idan to only have access to a limited set of these, how do I obtain this. For now, all I could find out that's working is the following (I'm going to name subfolders: sub0 to subx; while assuming wildcards work.) [CBD_Test_Environment:/*/CBD] &idan = r [CBD_Test_Environment:/*/CBD/sub0] &idan = r [CBD_Test_Environment:/*/CBD/sub1] &idan = [CBD_Test_Environment:/*/CBD/sub2] &idan = and this for all subfolders. What does not work (but would be nice) [CBD_Test_Environment:/*/CBD] &idan = [CBD_Test_Environment:/*/CBD/sub0] &idan = r Meaning CBD and all subitems are not accessible to idan, except the sub0 folder. The sandbox would (off course) have the CBD folder and only the sub0 subfolder This does work if I do not use the wildcards but the fully extended name. But you can imagine if I have to do such a thing for each branch which is created, this creates a huge access rule file which is hard to maintain (as we create a new branch for each bug which is reported) Can you confirm that the above mentioned issues are real issues? If there are workarounds, can you give some advice. As administrator for our subversion repositories, I like the central place for controlling the permissions, but the above items still make it a hard job. Best regards, Ing. Ignace Danneels Controls Design Engineer __________________________________________________________________________ TREMEC TORQUE TRANSFER SOLUTIONS Autobaan 20 B-8210 Loppem Phone: +32 50 288063 ignace.danne...@tremec.com www.tremec.com<http://www.tremec.com/> [cid:image001.jpg@01CCED94.64E0F970] ________________________________ Este correo electrónico es confidencial y exclusivamente para la(s) persona(s) a quien(es) se dirige. Queda estrictamente prohibida la distribución o copia del contenido de este correo. Si Usted ha recibido este correo por error le suplicamos notificar inmediatamente a la persona que lo envió y borrarlo definitivamente de su sistema. Si Usted proporcionó a Grupo Kuo, S.A.B de C.V. y/o afiliadas, filiales y/o subsidiarias (Grupo Kuo) por esta vía algún dato de tipo personal, Usted autoriza a Grupo Kuo la publicación, divulgación y/o transmisión de la información que haya insertado conforme al artículo 109 de la Ley Federal del Derecho de Autor. Grupo Kuo podrá en cualquier momento modificar o eliminar la información proporcionada, sin responsabilidad ni control sobre los enlaces a portales propiedad de terceras personas ajenas a Grupo Kuo. Contacto: datos.persona...@kuo.com.mx Puede consultar nuestro aviso de privacidad en www.kuo.com.mx This e-mail is confidential and for the exclusive use of the person(s) to whom it is addressed. You are hereby notified that any distribution or copy hereof is strictly forbidden. If you have received this e-mail by error, we kindly ask you to notify the sender and to delete it immediately. If you have provided Grupo Kuo, S.A.B. de C.V. and/or Grupo Kuo’s affiliates and/or subsidiaries (Grupo Kuo) through these means with any personal information, you hereby grant Grupo Kuo expressly authorization to publish, reproduce, divulge, publicly communicate and/or transmit the inserted information pursuant to article 109 of the Federal Copyright Law of Mexico. Grupo Kuo may at any time, modify or delete the information contained herein and is not responsible in any way of controlling the links to different portals nor on third parties not related to Grupo Kuo. Notwithstanding the foregoing, Grupo Kuo does not warrant the authenticity or reliability of the information related to third parties. Contact: datos.persona...@kuo.com.mx See our privacy policy in www.kuo.com.mx Outbound Security KUO
