Mercurial временно игнорирует версионные файлы - PullRequest
3 голосов
/ 09 декабря 2010

Мой вопрос по сути такой же, как здесь , но относится к ртути.У меня есть набор файлов, которые находятся под контролем версий, и одна операция сохранения изменяет довольно много файлов.Некоторые из полученных изменений важны для контроля версий, а некоторые из них просто бесполезны.Я могу "разбить" мусор на отдельные файлы.Эти ненужные файлы должны быть частью базовой проверки, чтобы они работали, но их содержимое (и изменения со временем) не так важны для контроля версий.Прямо сейчас я просто говорю всем нашим разработчикам не передавать эти файлы, но мы все забываем, и это создает много лишнего багажа в хранилище.Мне не очень нравится предложенное решение svn, потому что файлов довольно много, и я хочу, чтобы простой клон просто работал без всей этой дополнительной ручной работы, поэтому мне было интересно, есть ли у Mercurial лучшая альтернатива.Это вроде hg shelve, но не совсем, и вроде как игнорировать, но не совсем.Есть ли какое-то расширение hg, которое позволяет это?Может ли мерзавец сделать это?

Ответы [ 3 ]

3 голосов
/ 09 декабря 2010

Mercurial не поддерживает это.Правильный способ сделать это - зафиксировать thefile.sample, а затем попросить разработчиков (или лучше развернуть сценарий) сделать копию с thefile.sample до thefile, если thefile не существует.Таким образом, любой может обновить файл примера, но нет риска, что он внесет свои локальные изменения (скажем, в свою строку подключения к личной базе данных).

2 голосов
/ 10 декабря 2010

Aha!Таким образом, репозиторий и глобальные настройки TortoiseHG имеют список автоматического исключения, в котором вы можете определить список файлов, которые по умолчанию не будут проверяться при открытии диалоговых окон состояния, фиксации и полки.Таким образом, они все еще обнаруживаются, но пользователь должен проверить их, чтобы фактически сделать коммит.Настройки хранятся в hgrc, но они находятся под заголовком [tortoisehg], поэтому они не поддерживаются mercurial как таковыми.Тем не менее, это соответствует моим потребностям.

1 голос
/ 09 декабря 2010

Одним из решений этой проблемы является использование поддержки вложенного дерева (подмодуль в git), где «мусор» будет помещен в другой репозиторий (чтобы не загромождать основной репозиторий), при этом позволяя проверять все это в согласованным образом (правильная версия обоих репозиториев в синхронизации).

https://www.mercurial -scm.org / вики / Subrepository? Действие = показать и перенаправлять = subrepos

В git подмодули являются одним из решений этой проблемы, но они не настолько хороши в пользовательском интерфейсе. Вместо этого я сохраняю два полностью независимых репозитория и использую стратегию слияния поддеревьев, когда мне нужно обновить основное репо с помощью нежелательного репо: http://progit.org/book/ch6-7.html

...