Есть ли ртутное расширение, такое как SVN Propset?

Question

Мне нужно прикрепить пользовательские метаданные к моим исходным файлам, которые отслеживают через Mercurial. А Свойства SVN Команды - это именно то, что мне нужно.

Есть ли мгновенное расширение, которое предоставляет команды, похожие на propset, propget, propdel, так далее?

Если нет расширения, почему бы и нет?
Есть ли альтернативный/лучший подход для пользовательских метаданных при использовании Mercurial?
Пользовательские метаданные не полезны для кого -либо еще?
Продолжительное продление очень желательно, но еще не написано?

Дополнительная информация: Если это помогает. Метаданные, которые я отслеживаю, заключается в том, был ли каждый файл CodeReview, Unitted, QA'D и т. Д.

Answer 1

Философия Mercurial заключается в том, что вы отслеживаете файлы и только файлы. Вы даже не можете проверить пустую папку, потому что Mercurial не знает о папках!

Итак, вот ответы:

• Я не могу найти никакого расширения, которое делает то, что вы хотите. (Конечно, вы можете написать свой собственный.)

• Рукальный способ сделать то, что вы хотите, - это хранить данные в плоском файле и использовать некоторые сценарии для их обработки. :(

Похоже, у вас есть довольно хорошо продуманная система и хорошая инженерная практика в вашей компании, поэтому я не буду здесь педантичным, но можно привести к разумному аргументу, что ваш метод ничего не делает, кроме повреждения портативности. В свойствах нет ничего волшебного, я бы просто запустил svn proplist -v . На вашем дереве сбросьте это в скрытые файлы - что -то вроде .tracking - Просто явно объедините его вместе с обычными файлами. Это на самом деле не добавляет никакой работы, так как вам все равно нужно объединять свойства.

Я надеюсь, что это сработает для вас!

Answer 2

Меркуриальное соглашение состоит в том, чтобы разместить имя файлов .hg* в корень репозитория и используйте их в качестве словарей (какого -то рода), чтобы отобразить имена файлов со значениями свойства. Например, вместо svn:eol-style Расширение Hgeol использует .hgeol файл.

В случае отслеживания обзора кода, я бы порекомендовал написать еще одно расширение, которое позволяет манипулировать этими метаданными, и предоставить это удлинительное хранилище в своем состоянии в удобном для слияния формате.

Answer 3

Я собираюсь добавить к этому вопросу очень поздний квази -бесан Свойства SVN.

Насколько я могу судить, нет такого расширения для Mercurial. пока что.

Да, кажется, что ртутный способ отслеживать файлы и только файлы. И может случиться так, что они направляют такое расширение, чтобы поместить необходимые метаданные в ... repo/.hg* файлы.

ХОРОШО. Я играл с этим. Делать вещи вручную, прежде чем пытаться написать инструменты.

Ключевая слабость подхода к версии .HG Files заключается в том, что если вы посмотрите не TIP-версию, например, «Обновление HG -R Old-версия», вы получите старую версию метаданных.

Я думаю, что ключевым вещью, следовательно, может быть помещение метаданных в ... repo/.hg* файлы.

Но ... большинство операций должно выполняться с или по последней версии таких файлов. Т.е. я думаю, что такие версии метаданных «трансцендные» - т.е. они хотят быть версированными, но в идеальной ситуации вы можете представить их как наложенные на нормально версированные файлы, которые вы, возможно, проверили более старую версию.

Более того, во многих случаях вы хотите, чтобы разветвление таких файлов метаданных обрабатывалось отдельно. Например, представьте себе файл, в котором вы пытаетесь написать описание всех ветвей вместе. Возможно, сравнение филиалов, таких как «Branch1.1, является более недавней версией Branch1». Вы не хотите, чтобы это описание было ни в одной из ветвей; Или, скорее, вы хотите, чтобы это было на обоих браках, одновременно, и вы хотите, чтобы изменения были отражены на обеих ветвях.

Такое предполагаемое расширение либо будет работать на «hg cat-r tip ... репо/.hg-my-new-metadata». Или это каким -то образом накладывало бы версию файлов с обычной версией, трансцентрирующими файлами метаданных.

Я добился некоторого прогресса в том, чтобы сделать это с подрепонами:

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

Это позволяет мне проверить последние метаданные вместе с более старой версией файлов

Это не совсем, потому что проверка определенной версии SuperRepo может получить старые версии подрепо метаданных. Но, по крайней мере, новые версии находятся в подрепо.

Позвольте мне также отметить, что, независимо от того, помещаете ли вы метаданные в соседний подрепо или держите его в том же репо (но работаете на кончике), есть проблема, которую вы можете сделать

hg clone -r OLD-REVISION repo newrepo

Это вытащит метаданные позже, чем старое изменение. Включая метаданные, в которых говорится, что «старая ревизия проходила все тесты», то есть он лишит метаданные из более поздней пересмотра, которая может применяться к старому ревизии.

Эта же проблема происходит с тегами HG.

Можно сказать: «Ну, никогда не делай этого» - никогда не разделяй историю. К сожалению, это часто рекомендуется как способ «укоренить» репозиторий.

Кажется, что это трудно избежать с ртутью.