Y at-il une extension Mercurial comme svn propset?

Question

Je dois attacher des métadonnées personnalisées à mes fichiers sources à Mercurial via objet d'un suivi. svn Les commandes de propriétés sont exactement ce que je dois.

Y at-il une extension Mercurial qui fournit des commandes similaires à propset, propget, propdel, etc?

S'il n'y a pas une extension, pourquoi pas?
Y at-il une approche alternative / meilleure pour les métadonnées personnalisées lors de l'utilisation Mercurial?
Est-ce des métadonnées personnalisées ne sert à quelqu'un d'autre?
Est l'extension souhaitée cher, mais tout simplement pas encore écrit?

info : Si ça aide. Les métadonnées Je le suivi est de savoir si chaque fichier a été codereviewed, unittested, qa'd, etc. Ce besoin de données à la traçabilité et des fusions entre les branches / clones ne sont pas assez à grains fins.

Answer 1

La philosophie de Mercurial est que vous suivre les fichiers et les fichiers seulement. Vous ne pouvez même vérifier dans un dossier vide parce que Mercurial ne connaît pas les dossiers!

Alors, voici les réponses:

• Je ne peux pas trouver toute extension qui fait ce que vous voulez. (Vous pouvez écrire votre propre bien sûr.)

• La façon Mercurialful à faire ce que vous voulez est de stocker les données dans un fichier plat et utiliser des scripts pour traiter. : (

On dirait que vous avez un assez bien pensé système en place et de bonnes pratiques d'ingénierie dans votre entreprise, donc je ne vais pas être pédant ici à ce sujet, mais on peut faire un argument raisonnable que votre méthode ne fait rien, sauf blessure portabilité. Il n'y a rien de magique propriétés, je voudrais juste lancer un svn proplist -v . sur votre arbre, vidage des fichiers cachés - quelque chose comme .tracking - il suffit de fusionner explicitement avec vos fichiers normaux. Cela ne veut pas vraiment ajouter de travail depuis que vous avez à des propriétés de fusion de toute façon.

J'espère que les travaux pour vous!

Answer 2

La convention Mercurial est de mettre le nom des fichiers .hg* dans la racine du dépôt, et les utiliser comme des dictionnaires (de quelque nature) à des noms de fichiers à la valeur des propriétés. Par exemple, au lieu de svn:eol-style l'extension hgeol utilise un .hgeol fichier.

En cas de révision du code de suivi, je vous recommande d'écrire une autre extension qui permet la manipulation de ces métadonnées, et ont ce magasin d'extension de son état dans un format de fusion convivial.

Answer 3

Je vais ajouter une quasi-réponse à cette question très tard, car il est un que beaucoup, beaucoup, les gens en utilisant Mercurial, y compris moi, demandez - quelque chose que nous voulons avoir, et attendre d'avoir, après l'utilisation de d'autres outils tels que les propriétés svn.

Pour autant que je sache, il n'y a pas une telle extension pour Mercurial. encore.

Oui, la façon Mercurial semble être de suivre les fichiers et seuls les fichiers. Et il se pourrait que leur façon à droite une telle extension est de mettre les métadonnées nécessaires dans ... les fichiers repo / .hg *.

OK. Je joue avec ça. Faire des choses à la main, avant d'essayer d'outils d'écriture.

La principale faiblesse de l'approche des fichiers .hg versionné est que si vous consultez une version non-pointe, par exemple "Hg update -r VIEUX-VERSION", vous obtenez une ancienne version des métadonnées.

Je pense que l'élément clé, donc peut-être de mettre les métadonnées dans ... repo / .hg fichiers *.

Mais ... la plupart des opérations doivent être effectuées avec ou sur la dernière version de ces fichiers. C'est à dire. Je pense que ces fichiers de métadonnées versions « transcendent » - à savoir qu'ils veulent être versionné, mais dans une situation idéale vous pourriez les imaginer comme superposition sur les fichiers versionnés normalement que vous avez peut-être vérifiés sur une ancienne version de

.

En outre, dans de nombreux cas, vous voulez que le branchement de ces fichiers de métadonnées à traiter séparément. Par exemple. imaginez un fichier dans lequel vous essayez d'écrire une description de toutes les branches, ensemble. Peut-être comparer les branches, comme « branch1.1 est une version plus récente de Branch1 ». Vous ne voulez pas que cette description est de chaque branche; ou plutôt, vous voulez qu'il soit sur les deux brancges, en même temps, et vous souhaitez que les modifications soient reflétées sur les deux branches.

Une telle prolongation serait supposée fonctionner soit sur "chat hg tip -r ... repo / .hg-my-new-métadonnées". Ou il serait en quelque sorte le superposer Versioned des fichiers avec les fichiers de métadonnées version normalement transcendant.

J'ai fait quelques progrès à faire cela avec subrepos:

superrepo
   files // normally-versioned-files <-- a subrepo
   metadata // version transcending metadata <-- a subrepo

cela me permet de consulter les dernières métadonnées à côté d'une ancienne version des fichiers

Il est pas tout à fait, car vérifier une version particulière du superrepo peut obtenir les anciennes versions du subrepo de métadonnées. Mais au moins les versions les plus récentes sont en subrepo.

Permettez-moi de note également que, si vous mettez les métadonnées dans un subrepo voisin, ou le garder dans le même repo (mais fonctionnent sur la pointe), il y a un problème que vous pouvez faire

hg clone -r OLD-REVISION repo newrepo

Cela dépouilleront métadonnées plus tard que VIEUX-RÉVISION. Y compris les métadonnées qui dit que « VIEUX-RÉVISION passé tous les tests », à savoir qu'il dépouiller les métadonnées d'une révision ultérieure qui pourrait demander à l'ancienne-RÉVISION.

Ce même problème se produit avec des balises hg.

On pourrait dire « bien, jamais le faire » - strip jamais sur l'histoire. Malheureusement, ce qui est souvent recommandé comme un moyen de « rangement » du dépôt.

Il semble difficile d'éviter cela avec Mercurial.