Peut-on utiliser Mercurial pour préserver les autorisations de fichiers?

Question

J'ai vu un certain nombre de messages de blog, et ont vécu pour moi-même, qu'Mercurial ne permet pas de conserver les autorisations sur les fichiers poussé d'un repo à un autre. Personne ne sait d'une Mercurial extension qui permettrait de préserver les autorisations? (Je suis en supposant qu'elle ne peut pas être fait avec un crochet, parce que ce n'est qu'un crochet de savoir sur les autorisations à l'origine de repo?)

Demande d'élaboration:

• Si la seule modification d'un fichier est un changement dans les autorisations (par exemple, chmod o+r filename), les tentatives de commettre le fichier échouer avec un message disant que le fichier n'a pas changé.

• Si je commets un fichier avec les permissions 600 (rw-------), puis cloner le repo, le même fichier dans le clone a des autorisations 664 (rw-rw-r--):

  : nr@yorkie 6522 ; hg clone one two
  updating working directory
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  : nr@yorkie 6523 ; ls -l one two
  one:
  total 4
  -rw------- 1 nr nr 8 Aug 18 21:50 foo
  
  
  two:
  total 4
  -rw-rw-r-- 1 nr nr 8 Aug 18 21:51 foo
  

Cet exemple montre que l' hg clone ne permet pas de conserver les autorisations, mais hg push ne conserve pas non plus.

Dans mon application, un repo est sur un public le chemin accessible, et il est d'une importance majeure qui

• Plusieurs utilisateurs ont le droit de modifier le repo

• Les fichiers dans le public des pensions de devenir lisible uniquement lorsqu'il est explicitement fait lisible.

Answer 1

OK, j'ai hate de répondre à ma propre question, mais il semble que cela peut être fait à l'aide de crochets et un outil auxiliaire (et un peu de chewing-gum et de mise en balles de fil):

1. Obtenez David Hardeman de Metastore, qui enregistre et restaure les métadonnées du fichier.

2. Modifier les sources de sorte qu'il va ignorer le répertoire .hg ainsi que .git.

3. Utiliser les éléments suivants Mercurial crochets:

    precommit.meta = metastore -s
   
   
    changegroup.update = hg update
    update.meta   = /usr/unsup/nr/bin/metastore -a
   

Vous devez ajouter l' .metadata le fichier de la mise en pension.

Cette lashup fonctionne la plupart du temps, mais si vous modifiez uniquement les autorisations et de propager, vous aurez à exécuter metastore -s afin de pousser ces changements dans la .le fichier de métadonnées où hg va voir le changement, sinon la validation pense que rien n'est nouveau.

Answer 2

Que penser de l'utilisation de cette solution de l' Mercurial FAQ:

Si vous utilisez Mercurial config la gestion des fichiers, vous pouvez piste propriétés du fichier (de propriété et de autorisations) trop. Mercurial uniquement pistes le bit d'exécution de chaque fichier.

Voici un exemple de la façon de sauver les propriétés ainsi que les fichiers (travaux sous Linux, si vous avez l' aclpaquet installé):

# cd /etc && getfacl -R . >/tmp/acl.$$ && mv /tmp/acl.$$ .acl
# hg commit

C'est loin d'être parfait, mais vous obtenez l'idée. Pour une solution plus complexes, découvrez etckeeper.

Answer 3

C'est très tard, mais pour le cas particulier du répertoire / etc, etckeeper semble intéressant.

Answer 4

Ce n'est pas une bonne idée de stocker des autorisations dans VCS. Cependant, Mercurial prend en charge l'indicateur "exécutable" (ce n'est pas la même chose que les autorisations, bien que l'indicateur d'exécutable Unix fasse partie des autorisations).