Mercurial Annuaire des règles d'accès

Question

J'ai un dépôt Mercurial avec la structure de répertoire suivant:

/ 
/system 
/applications 
/applications/client1 
/applications/client2 
/applications/client3 

Je suis au service de la pension sur un sous-domaine apache sur http (pas encore ssl) et souhaitez restreindre l'accès à pousser, tirer et engage bien sûr. Généralement, je ne veux pas que certains utilisateurs voient les répertoires du tout et pas l'histoire des répertoires!

1. Y at-il une chance de restreindre l'accès à un répertoire dans un référentiel Mercurial.
2. Comment puis-je donner accès au dossier client 1 uniquement pour client1, client2 uniquement pour client2 sur un système Linux? Note: Je ne veux pas diviser le dépôt en sous-dépôts si ce n'est pas nécessaire!
3. Si cela ne fonctionne pas sans sous-dépôts, quelqu'un peut-il me dire comment faire avec des sous-dépôts dans ce cas avec ma structure de répertoire.

Je suis perdu :(

Answer 1

Puisque vous avez tout dans 1 référentiel, aucune

tl; dr. Un dépôt est toujours complet, et si vous pouvez cloner, vous peut tout voir, il n'y a aucun moyen de restreindre l'accès au contenu dans un clone local, pour un clone hébergé par le serveur central.

---

un serveur Mercurial peut traiter avec autorisation en deux façons:

1. Il peut restreindre l'accès au référentiel
2. Il peut utiliser des crochets pour éviter des poussées avec le contenu que l'utilisateur ne peut pas modifier

Le premier type rendrait toute la lecture de dépôt -seulement, ou indisponible. Cependant, si un utilisateur a un accès en lecture, il sera capable de cloner, et de voir, tout le dépôt, l'historique et les fichiers. Mais, vous pouvez empêcher ce même utilisateur de modifier la copie centrale en lui interdisant les poussées. Cela signifierait que cet utilisateur pourrait faire tout ce qu'il voulait avec son propre clone privé, mais il ne serait pas capable de ramener ces changements au clone central.

L'autre type vous permettrait de contrôler où les changements ont été autorisés à se produire un peu plus précis. Cependant, notez que, encore une fois, un utilisateur sera en mesure de cloner, et de voir, l'ensemble du dépôt.

En outre, l'utilisateur sera également capable de faire ce qu'il veut avec son propre clone personnel. Cependant, alors que les poussées vers le référentiel central ne sont pas totalement interdites avec ce type d'autorisation, un crochet regarderait les changesets poussés, et si, par exemple, vous décidez que cet utilisateur n'est pas autorisé à pousser les modifications au contenu "client2", n'importe quel changesets qu'il essaye de pousser sera avorté. En d'autres termes, l'utilisateur peut modifier son clone privé, y compris modifier des choses dans "client2", mais s'il commet un changeset avec des changements "client2", il ne pourra pas retourner dans le dépôt central. . Il devrait ensuite se déshabiller, ou se débarrasser autrement de ces changesets, avant que ses poussées ne passent.

Donc, pour résumer:

1. Vous pouvez interdire à l'utilisateur du clonage tout à fait, cela rendrait le dépôt ensemble indisponible pour lui
2. Vous pouvez interdire pousse, mais autoriser le clonage
3. Vous pouvez utiliser des crochets Néanmoins, si l'utilisateur est capable de créer un clone, ce clone est toujours complet et non restreint sur l'ordinateur de l'utilisateur. Vous ne pouvez pas restreindre l'accès dans ce clone, tout ce que vous pouvez faire est le point 1, interdire à l'utilisateur de cloner pour commencer.

Answer 2

Vous pouvez utiliser le ACL Extension, qui est maintenant distribué avec Mercurial par défaut. L'extension peut restreindre toutes les actions Hg par répertoire, sans en ayant recours à l'utilisation de sous-dépôts.

De plus, vous pouvez restreindre l'accès par branche ou par dossier.