title: Alternative to path based access control in Subversion
body: <p>Is there any alternative to path based access control in Subversion?</p>
  
  <p>I'm dealing with a repository that contains files that are subject to <a href="http://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations" rel="nofollow" title="ITAR">ITAR</a>. Several teams will have access to the repository, but some of them are not allowed to even <strong>see</strong> ITAR sensitive data, so we're talking about read access here, not just commit access.</p>
  
  <p>Now I have several options for dealing with this.</p>
  
  <p>The first is simply listing out all the files that have access restrictions. The problem with that is that we need to know what the filename is going to be before it can be added to the auth file. So a developer creates an ITAR sensitive file, e-mails the full path to the svn admin, who then adds it to the auth file. Only then can the developer actually add and commit the file.</p>
  
  <p>Another solution is to have two directories at the top level, say <code>general</code> and <code>mil</code>, with the same subdirectories. That way, all sensitive files go into <code>mil</code> and all others go into <code>general</code>. That gives me a short and sweet auth file, but the downside is that if a file <em>becomes</em> ITAR sensitive, it needs to be moved from one tree to the other. We can work with that, but it's not optimal.</p>
  
  <p>What I would <em>like</em> to have, is property based access control. If we could just add a property, say <code>mil</code> or <code>itar:reason</code> to a file and restrict access based on that, that would be ideal. Developers could add the property before first commit, or when a file becomes sensitive. However, except if I have missed it, that's not possible.</p>
  
  <p>So does anyone see any other solution to this problem?</p>