Hi Jan > I've changed my mind, there is something that may be better than > externals, although it requires a little trick. > You should be able to create a commit hook that checks if the authz file > reflects the restrictions you want on a specific folder > (*/thesecretfolder/*) for the branch > (/branches/somebranch/thesecretfolder) and if not add the restrictions.
I get your drift but may I check I am understanding you correctly? The authz file would contain: */thesecretfolder/* @privileged_group = rw * = svn does not expand wildcards in authz but I guess it will not complain about such an entry. The hook reads authz and does the comparison of the actual commit path against this wildcard path using regular expressions (or whatever). Am I right so far? The hook must then check that the committer has rights to commit to that path. So the hook uses the access permission specification in the above entry, and checks that the committer belongs to 'privileged_group'. Then the hook allows or blocks the commit. Am I correct? > The advantage of this approach over externals is that you'll have atomic > commits, the version of the 'secretfolder' will be linked to the versions > in the rest of the repository,... And if one day the suggested wildcard > feature is implemented all you'll have to do is update the authz file to > contain a wildcard, remove the commit hook and you're done. Yes, I like your idea, thanks. I am quite opposed to using externals for this since I realised that externals are not well supported in branching and merging. I did think of another approach before receiving your suggestion. I thought of having a proprietary 'my_authz' file which allows wildcards. Then our own mangler would check what branches exist, read our my_authz and generate a real authz file with all the necessary expanded paths and permissions. Could be run regularly by cron (or whatever). However, your suggestion is more elegant. Not sure which would be more efficient. BR David
