Solución:
A veces, los permisos pueden tardar un poco en sincronizarse.
http://msdn.microsoft.com/en-us/library/ms400712.aspx#doesnottake
Esto es frustrantemente estúpido. Entonces, si tiene este problema similar, pero no puede encontrar los permisos reales que necesita cambiar y parece que no puede encontrar dónde se establecen estos permisos a través de su IDE, es porque realmente necesita acceda a los permisos haciendo clic con el botón derecho en el Proyecto y seleccionando Avanzado-> Seguridad, no yendo a Equipo-> Configuración de proyecto de equipo / Configuración de colección de proyecto de equipo-> Seguridad. También puede hacer esto con la línea de comandos tf usando los comandos especiales tf de tf, pero tuve problemas con eso.
Si el usuario (o grupo de seguridad de AD) que modificó ya era conocido por el sistema, los cambios deben ser instantáneos. La sincronización solo entra en juego en el escenario opuesto: un grupo de seguridad ya tenía PendChange permitido, luego un administrador de Windows agregó un nuevo usuario a ese grupo. TFS no sabrá sobre el cambio hasta que hable con el directorio activo durante la próxima sincronización programada.
La causa más probable de lo que está viendo es la herencia de permisos. Incluso si al usuario se le permite explícitamente un permiso, cualquier ACL de denegación que se le aplique lo anulará. Por ejemplo, las ACL establecidas en un elemento principal pueden heredarse. Del mismo modo, si el usuario es miembro de dos grupos (por ejemplo, contribuyentes y lectores), podría tener ACL en conflicto en juego, y Denegar siempre ganará.
Además, el modelo de herencia se modificó ligeramente en 2008 SP1. Ver:
- http://blogs.msdn.com/mohamedg/archive/2009/03/23/deny-revisited.aspx
- http://blogs.msdn.com/dstfs/archive/2008/12/12/how-to-allow-access-to-a-child-folder-without-allowing-access-to-the-parent-folder- in-tfs-source-control.aspx