Есть ли расширение Mercurial, такое как svn propset? - PullRequest
7 голосов
/ 14 декабря 2010

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

Существует ли расширение Mercurial, которое предоставляет команды, подобные propset, propget, propdel и т. Д.

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

дополнительная информация : Если это поможет. Метаданные, которые я отслеживаю, - это был ли каждый файл повторно просмотрен, проверен на единицу, проверен и т.д.

Ответы [ 3 ]

4 голосов
/ 15 декабря 2010

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

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

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

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

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

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

4 голосов
/ 15 декабря 2010

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

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

0 голосов
/ 27 июля 2012

Я собираюсь добавить очень поздний квази-ответ на этот вопрос, поскольку многие, многие, использующие Mercurial, включая меня, спрашивают - то, что мы хотим иметь и ожидаем получить после использованиядругие инструменты, такие как svn properties.

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

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

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

Ключевой недостаток подхода с версионными файлами .hg заключается в том, что если вы извлекаете версию без подсказки, например, "hg update -r OLD-VERSION",вы получаете старую версию метаданных.

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

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

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

Я добился некоторого прогресса в этом с помощью подпунктов:

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

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

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

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

hg clone -r OLD-REVISION repo newrepo

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

Та же самая проблема возникает с тегами hg.

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

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

...