#version-control #mercurial #hgignore
#контроль версий #mercurial #hgignore
Вопрос:
Это вопрос процесса, поэтому может быть более одного правильного ответа. Я возьму все, что у меня есть сейчас.
Моя команда недавно перешла на использование Mercurial (из Subversion), и по большей части нам нравится новая мощность. Однако есть несколько вещей, которые снижают производительность. Одной из таких вещей является управление .hgignore файлом.
В соответствии с установленной литературой и советами «некоторых парней в Интернете» :), наша команда поддерживает .hgignore обновление файла, чтобы hg addremove всегда поступать правильно. Кроме того, отсутствующие файлы, которые необходимо добавить, являются причиной № 1 сбоев сборки, поэтому важно, чтобы hg st возвращались только те файлы, которые действительно нуждаются в действии.
Проблема в том, что, поскольку мы всегда добавляем новые игнорирования в нижнюю часть файла, это всегда вызывает конфликт слияния, если два человека вносят .hgignore изменения. (Большинство людей используют клиент TortoiseHg, который добавляет в конец файла.) Результатом этого является то, что примерно в половине случаев файл изменяется, человек, который его изменяет, должен обрабатывать слияние .hgignore . Это очень похоже на то, чтобы возиться с внутренностями нашего контроля версий.
Это заставляет разработчиков не хотеть добавлять файлы в .hgignore , так как они знают, что для обработки потребуется как минимум несколько дополнительных минут. У нас довольно большой проект с довольно большой командой, которая претерпевает постоянные изменения. Новые артефакты сборки появляются довольно регулярно, поэтому проблема, похоже, не исчезает. На самом .hgignore деле это не сильно стабилизируется, поскольку проект сильно меняется. (Что само по себе, конечно, является другой проблемой.)
«Правильная» вещь, которую нужно сделать, это «принять обе стороны» почти всегда. Технически два человека могли изменить одну и ту же предыдущую строку с помощью текстового редактора, но это маловероятно. Маловероятно, что даже если подход «использовать оба» не удался, последствия незначительны.
Итак, я задаю вопрос сообществу: как я могу улучшить ситуацию? Есть ли изменение процесса, которое смягчило бы это? Есть ли инструмент для автоматического принятия обеих сторон? Могу ли я как-то автоматизировать слияние? Есть ли флажок, который я могу проверить, чтобы волшебным образом решить проблему :)?
Редактировать 1: Вот (очевидно отредактированная) версия моего текущего .hgignore . Вы можете легко заметить, что используется несколько разных технологий. Несколько частей кода находятся в процессе перехода с одной технологии на другую (например, с VB на C #). Это приводит к изменению набора артефактов сборки и необходимости обновления файла.
syntax: glob
*.obj
*.tds
*.map
*.il?
*/obj/*
*/lib/*
*/pch/*
Foo/Engine/frezbat/DocFiles.hpp
Foo/Engine/personal_defines.h
Foo/Engine/revision.cpp
Foo/Engine/frobbish/uLinkHlp.hpp
Foo/Engine/dll/XMLData/**.xml
Foo/Engine/dll/*.syslog
Foo/Engine/dll/*.log
Foo/Engine/dll/Scripts
Foo/Engine/dll/Linked Models
Foo/Engine/dll/prv
Foo/Engine/dll/pub
Foo/Engine/dll/failures.txt
Foo/Engine/dll/users.prm
Foo/Engine/tools/SrvIface/**.dll
Foo/Engine/tools/SrvIface/**.exe
*/dll/*.ini
*/dll/*.exe
*/dll/*.dll
*/quux_obj/*
*.dbg
*~
scripts/backupPath.txt
*.local
*.orig
FooDoc/FooDoc/bin/*
FooDoc/FooDoc/FooDoc.suo
FooDoc/FooDoc/FooDoc.vbproj.user
FooDoc/FooDoc_Setup/Release
Foo/Engine/dll/FooObjects.pdb
Foo/Engine/dll/FooObjects.tlb
Foo/Engine/dll/FooObjects.xml
Foo/Engine/dll/InitechDebugTimer.txt
*.dsk
Foo/Engine/dll/Preferences/CustomToolbar.ini
Foo/Engine/Engine.~dsk
Foo/Engine/dll/ApplicationSettings.fooprefs
Foo/Engine/dll/Foo.cgl
Foo/Engine/dll/IniShare.mem
Foo/Engine/baz_obj/*
Foo/Engine/baz_pch/*
*/dll/*.drc
*.~dsk
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe.manifest
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe.config
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe
InitechBaz/InitechBaz/bin/Debug/InitechBaz.exe.config
scripts/TestComplete/Ottertech_Replay/Log/*
scripts/TestComplete/Ottertech_Replay/[*
relre:ReSharper*
relre:_UpgradeReport_Files
glob:*.suo
glob:*.pdb
*.swp
Foo/Engine/FooObjects/FooObjects/bin/x86/
FooDoc/MCtoDAT/MCtoDAT/bin/x86
FooDoc/Deploy
Foo/Engine/installers/initech-build/bin/*
scripts/TestComplete/Users/*
Foo/Engine/dll/MCtoDAT.xml
FooDoc/Deploy/*
scripts/TestComplete/Ottertech_Replay/Log/*
scripts/TestComplete/Ottertech_Replay/[*
*.orig
Foo/Engine/installers/icon-installers-bin/*
Foo/Engine/Quux/Server/*.esp
Foo/Engine/Quux/BrapServer/*.esp
Foo/Engine/installers/bin/*.exe
Foo/Engine/installers/quux/encryptedsql/*.esp
Foo/Engine/tools/tempfile.tmp
*.pch
*.#*
*.#??
Foo/Engine/dll/frabbing.lib
re:^.*.#[0-9][0-9]$
Foo/Engine/Foo/FooObjects/FooObjects/FooObjects.xml
FooDoc/MCtoDAT/MCtoDAT/MCtoDAT.xml
*.sln.cache
FooDoc/TestFooObj/TestFooObj/bin/
*.user
Foo/Engine/FooObjects/FooObjects/FooObjects.xml
Foo/Engine/FooObjects/FooObjects/FooObjects.xml
FooDoc/MCtoDAT/MCtoDAT/MCtoDAT.xml
*/Debug Installer/*.dll
*/Debug Installer/*.tlb
*/Debug Installer/*.xml
*/Debug Installer/*.msi
*/Debug Installer/*.exe
FooDoc/FooDoc_Setup/Debug/*
re:(?i).*/UpgradeLog.xml
*.sln.cache
Комментарии:
1. Какие изменения вы постоянно вносите в этот файл? Довольно редко бывает, что в этом файле действительно много оттока.
2. Я опубликовал файл, чтобы вы могли видеть. Одной из причин изменений является тот факт, что в ряде областей происходят изменения в инструментах и технологиях. Теоретически, это должно в конечном итоге закончиться, но к тому времени мы, вероятно, будем делать что-то подобное в другой области.
3. Хорошо, помимо его некоторого уплотнения, например, объединения всех каталогов и папок bin, obj и .tmp и т. Д. Тогда, я думаю, вам придется продолжать слияние. Beyond Compare — очень хороший инструмент слияния (на мой взгляд), и у него есть действие «поверните налево, затем поверните направо». Не автоматически, но все равно это довольно легко сделать. Возможно, стоит посмотреть.
4. Хех, это именно то, что мы используем. Я даже распространяю изображения с выделенной опцией «взять влево, затем вправо», чтобы люди знали, как это сделать.
Ответ №1:
Обычно в начале проекта происходит шквал изменений в файлах игнорирования, но это довольно быстро улаживается. Я предполагаю, что вы неэффективно используете подстановочные знаки. Если вы не можете придумать, как использовать подстановочные знаки в вашей ситуации, вам, вероятно, нужно спроектировать свой код так, чтобы все вновь созданные игнорируемые файлы помещались в один каталог. Например, помещение всех артефактов сборки в каталог «build». Это немного больше предварительной работы в ваших сценариях сборки, но также помогает с такими вещами, как завершение табуляции, поскольку в ваших исходных каталогах есть только исходные файлы.
Комментарии:
1. На самом деле это то, что я и предполагал сначала. Я подумал, что это довольно быстро успокоится, поскольку все артефакты сборки были добавлены к игнорируемым. Кроме того, у вас есть отличная точка зрения о каталоге сборки. Улучшение этого процесса входит в нашу дорожную карту, но было бы неплохо иметь решение, которое мы можем реализовать в краткосрочной перспективе. Я заметил, что по мере разработки проектов добавляется довольно много новых артефактов сборки, поэтому урегулирование происходит не так, как я ожидал.
2. Я подозреваю, что, возможно, OP может опубликовать выдержку, поэтому мы можем расширить этот ответ с помощью glob и или regex, чтобы сопоставить их все.
3. Увы, кажется, что ответ действительно «смирись и разберись». Хотя это и не удовлетворяет, по крайней мере, я знаю, что не стоит тратить на это кучу времени. Спасибо за помощь.
Ответ №2:
Переместите build-root за пределы дерева репозитория и получите исходные тексты для builder в результате hg export . Таким образом, вы можете убить двух зайцев одним выстрелом
- объекты сборки не будут мусорить в репозитории
- вы можете убедиться, что все необходимые файлы находятся в репозитории
Ответ №3:
Как и любой инструмент, Mercurial может зайти так далеко. Как указывалось ранее, большинство структур проекта имеют тенденцию к стабилизации через некоторое время, что делает ваши проблемы менее актуальными в стандартном варианте использования, чем в вашем собственном.
В вашем случае вполне может быть, что вам просто придется с этим смириться.
Одной из альтернатив было бы реструктурировать ваш проект таким образом, чтобы все ваши игнорируемые файлы располагались рядом или иным образом указывались шаблоном подстановочных знаков. Я бы посоветовал не делать этого, если единственной причиной является необходимость устранения проблем с игнорированием управления. Другими словами, особенности или ограничения вашей системы управления версиями не должны влиять на структуру проекта.
Тем не менее, обычно существуют подлинные силы, работающие над созданием стабильной структуры проекта, силы, которые выходят за рамки контроля версий. Например, разработчики должны быть знакомы с проектом, а постоянные изменения ухудшают знакомство. По-видимому, это не тот случай, когда вы игнорируете исходный код.
Я знаю, что это не поможет далеко ответить на ваш вопрос, но я чувствую, что проблема лежит за пределами системы управления версиями и что в вашем проекте эти другие силы перестали оказывать влияние.