I think I see what you're saying, but there's no way we could keep permissions updated without doing it at a repository level. We have hundreds of repos, and hundreds of branches within those repos. Our permissions are set at the repository level, usually for multiple groups (Contractors, Program Managers, Developers, Quality, Etc).
Our projects are ongoing...just some portions are closing out. Because of that, we have multiple repositories that all of our developers work with (alongside outside collaborators), to continue production. However, in this instance one individual branch within needs to be made R/O, while the rest of the branches (and there are hundreds) needs to continue to allow MOST of the permissions to give almost full R/W.
For instance, I have a ticket that says:
Due to an issue we had with an XProject's repository making changes on an YProjects sync branch, I would like to limit changeset modification (creation & deletion) on the "/main-0/dev/Object/SpecificBranch" branch for the following repositories:
repo1@plastic-server1
repo2@plastic-server1
repo3@plastic-server1
repo4@plastic-server1
repo5@plastic-server2
repo6@plastic-server2
Initiating a sync shouldn't be affected, but no user should be allowed to create or delete changesets. These will essentially be read-only branches.
So with that said, 6 branches, for 6 different repos, on 2 different servers, need to be made R/O, while the rest need to be R/W as normal.
The permissions that our developers have per repo, standard are as follows:
Am I doing this all wrong? If so, please correct me, but it seems almost impossible to set permissions to allow/deny at a branch level, without hiring two people to administer these servers. I'm just trying to automate it a little better if possible, to save the daunting task of repetitive permissions changes in the future.