2010-05-17 13 views
6
Ubuntu: Jaunty 
Mercurial: 1.3.1 
Access: ssh (users john and bob) 
File permission: -rw-rw---- 1 john john 129276 May 17 13:28 dirstate 
User: bob 
Command: 'hg st' 
Response: 

**abort: Permission denied: /our/respository/.hg/dirstate** 

Obviamente mercurial no puede dejar que bob vea el estado porque el archivo que necesita leer me pertenece.¿Cómo establecer permisos para que dos usuarios puedan trabajar en el mismo repositorio de hg?

Así que cambio los permisos para permitir que bob lea el archivo y todo está bien, hasta que vuelva a intentar hacer algo, por lo que las situaciones se invierten. Ahora él posee el archivo y no puedo leerlo.

Así que configuré un grupo de "committers" y tanto john como bob pertenecen al grupo, pero aún así violonchelos con la propiedad y los permisos cuando uno u otro commit.

Además, cada vez que uno de nosotros agregue un archivo al repositorio, el archivo es propiedad exclusiva del autor. Eso está bien para mí, ya que estoy lo suficientemente familiarizado con chmod, pero presenta un gran problema para bob cuando me niego a concederle permiso. Supongo que solo necesitamos un gancho post-commit para eso; pero solo para incluir este síntoma ...

¿Cómo lo configuramos para que dos inicios de sesión diferentes en el mismo grupo puedan comprometerse con el mismo repositorio sobre ssh?

Respuesta

1

A largo plazo, la solución de bit adhesivo tampoco funcionaba.

Lo que ha funcionado es poner los comandos chmod/chgrp en un script bash y enseñar al diseñador cómo ejecutarlo.

#!/bin/bash 
chgrp -R foo /foo/development/templates 
chgrp -R foo /foo/development/media 
chgrp -R foo /foo/development/static 

chmod -R g+w /foo/development/templates 
chmod -R g+w /foo/development/media 
chmod -R g+w /foo/development/static 
3

usando grupos unix: vea el método del sistema de archivos here.

13

Debe establecer el "grupo de bits adhesivos" en todos los directorios relevantes. Ese bit de permisos dice que cualquier archivo o directorio creado en esos directorios debe tener propiedad de grupo del grupo del directorio padre, no del grupo primario del usuario creador.

Puede arreglar las cosas por ir al nivel superior de toda tu repositorio (hg root) y la ejecución de estos comandos:

chgrp -R committers . 
chmod -R ug+=rwX . 
find . -type d -print0 | xargs -0 chmod 2775 # or 2770 if other can't read 

Ese primer comando da propiedad de grupo de nuevo a committers para todos los archivos y directorios. El segundo comando se asegura de que los propietarios y miembros del grupo puedan leer y escribir todos los archivos y directorios y que puedan descender todos los directorios. El tercer comando enumera solo los directorios (omitiendo archivos) y luego establece el bit de grupo de barras en ellos. Una vez que haya terminado, los permisos para los directorios se verán así: rwxrwsr-x

Solo tiene que hacer esto una vez, y si lo hace antes de crear el repositorio, no necesita usar find ya que el bit del grupo adhesivo será heredado por todos los directorios. Se hizo de la misma manera para CVS y svn en los viejos tiempos.

+1

Tienes razón. El secreto es el bit adhesivo ... "chmod g + s .hg .hg/store .hg/store/data" parece haber hecho las cosas 'tan-tan-tan-buenas'. –

+0

Sí, eso arreglará cualquier archivo nuevo agregado. El resto de esas cosas solo era para reparar archivos ya creados. –

Cuestiones relacionadas