subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignace Danneels <>
Subject Subversion related issues
Date Wed, 08 Jul 2015 15:42:42 GMT

I posted a question on the community page (see link below) and markphip replied.

The post is shown below

Issue 1

The access rule contain:
idan = ignace.danneels

sol_dev = &bwal,&idan

the I would prevent that user to access a specific folder by putting
&idan = rw


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:

Because the CBD folder also contains xml files, which are useless for one specific group,
I also wanted to change the rule as follows:

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

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.)
&idan = r
&idan = r
&idan =
&idan =
and this for all subfolders.

What does not work (but would be nice)
&idan =
&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
Autobaan 20
B-8210 Loppem
Phone: +32 50 288063<>



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: Puede consultar nuestro aviso de
privacidad en

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:
See our privacy policy in

Outbound Security KUO
View raw message