Является ли Mercurial .hgignore моей единственной опцией для обработки сотен временных файлов, сгенерированных при компиляции?

Question

Я был по всему Google и ТАК искал кого-то, кто задал этот вопрос, но я выхожу совершенно пустым. Я заранее извиняюсь за длительный обходной способ задать вопрос. (Если бы мне удалось выяснить, как решить проблему, возможно, мне удалось бы найти ответ.)

Как управлять большими проектами в Mercurial, , когда в процессе сборки / компиляции создаются сотни временных файлов для создания конечного результата ?? Является ли .hgignore только ответ?

Пример сценария:

У вас есть проект, который хочет использовать какой-то пакет с открытым исходным кодом для какой-либо функции и должен скомпилировать из исходного кода. Итак, вы идете за пакетом. un-.tgz, а затем поместите его в свой собственный репозиторий Mercurial, чтобы вы могли начать отслеживать изменения. Затем вы вносите все свои изменения и запускаете сборку.

Вы проверяете свой конечный результат, довольны результатами и готовы отправить обратно в локальный клон репозитория. Таким образом, вы делаете hg status, чтобы проверить свои изменения перед фиксацией. Результаты hg status заставляют вас немедленно начать использовать все те слова, которые могли бы стыдить вашу мать - потому что теперь у вас есть экраны и экраны "build cruft".

Ради аргумента скажем, что этот пакет - MySQL или Apache: то, что

1. вы не контролируете и будете регулярно меняться,
2. оставляет много беспорядка во многих местах, а
3. нет никакой гарантии, что фракция не изменится каждый раз, когда вы получаете новую версию из внешнего источника.

Ух ты что? Над конкретным проектом, вызывающим эту тревогу, будут работать несколько разработчиков в нескольких физических местах, и поэтому он должен быть максимально простым. Если будет слишком много вовлеченных, они не собираются это делать, и у нас будет большая проблема в наших руках. (К сожалению, некоторые старые собаки не заинтересованы в изучении новых трюков ...)

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

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

Мы не можем быть единственными, кто столкнулся с этой проблемой. Так что же такое «правильное» решение? Являемся ли мы единственным средством, чтобы попытаться создать чрезвычайно интеллектуальный файл .hginore? Это вызывает у меня беспокойство, потому что если я скажу Mercurial «игнорировать все в этом каталоге, о котором я вам еще не говорил», то что произойдет, если следующий примененный патч добавит файлы в этот игнорируемый каталог? (Mercurial никогда не увидит этот новый файл, верно?)

Надеюсь, это не совсем глупый вопрос с очевидным ответом. Я много раз собирал исходники, но мне никогда не приходилось применять контроль версий. Кроме того, мы новичок в Mercurial.

Answer 1

Два варианта:

1. Лучшим вариантом является сборка из дерева, если вы можете. Это сборка, в которой вы размещаете объектные файлы за пределами исходного дерева. Некоторые системы сборки, такие как CMake , поддерживают это напрямую. В других системах вам повезло, так как вышестоящий проект должен был добавить поддержку этого в их Makefile или аналогичном.

2. Более общий вариант - указать Mercurial игнорировать определенные типы файлов , а не целые каталоги. По моему опыту это хорошо работает.

Чтобы протестировать второй вариант, я хотел скомпилировать Apache. Однако для этого требуется APR, поэтому я протестировал его. После проверки в чистом apr-1.3.8.tar.bz2 я сделал ./configure; make и посмотрел на вывод hg status. Первые несколько патентов были легкими:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*

Остальные новые файлы выглядят так, как будто они являются конкретными файлами, сгенерированными в процессе сборки. Их тоже легко добавить:

% hg status --unknown --no-status >> .hgignore

Это также добавило .hgignore, так как я еще не запланировал это для добавления. Удаление, которое я закончил с этим .hgignore файлом:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*
.make.dirs
Makefile
apr-1-config
apr-config.out
apr.exp
apr.pc
build/apr_rules.mk
build/apr_rules.out
build/pkg/pkginfo
config.log
config.nice
config.status
export_vars.c
exports.c
include/apr.h
include/arch/unix/apr_private.h
libtool
test/Makefile
test/internal/Makefile

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

Answer 2

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

Answer 3

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

По крайней мере, вы можете зарегистрироваться в .hgignore и поделиться им со своими разработчиками. Таким образом, работа выполняется только один раз.

[Редактировать] Однако, по крайней мере, как заметил Мартин Гейслер, возможно, иметь полные спецификации пути в вашем файле .hgignore; следовательно, вы можете иметь test/Makefile в .hgignore и по-прежнему иметь уведомление Mercurial о новом test2/Makefile

Его процесс создания файла должен дать вам почти то, что вы хотите, и вы можете настроить его оттуда.

Answer 4

Как насчет сценария оболочки (или любого другого), который рекурсивно обходит ваш каталог сборки, находит каждый файл, созданный после запуска процесса сборки, и перемещает все эти файлы (конечно, вы можете указать исключения) в cruft_dir подкаталог. Тогда вы можете просто положить cruft_dir/* в .hgignore.

РЕДАКТИРОВАТЬ: я забыл добавить, но это довольно очевидно, что этот сценарий оболочки запускается автоматически, как только ваша сборка заканчивается. Возможно, она даже называется последней командой в вашем файле Makefile / ant / what.

Answer 5

Если файлы, которые вы хотите отслеживать, уже известны hg, вы можете hgignore все. Затем вам нужно использовать hg import для добавления патча, а не просто использовать команду patch (поскольку hg нужно знать, нужно ли отслеживать некоторые новые файлы).

Answer 6

Один из возможных вариантов - очистить рабочий каталог после проверки сборки.

make clean
hg status

Конечно, вы можете не захотеть очищать свой проект, если на его сборку уходит более нескольких минут.