Следует ли хранить сгенерированный код в системе управления версиями

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

У нас есть несколько классов, которые создаются во время сборки для обработки операций с БД (в этом конкретном случае с SubSonic, но я не думаю, что это очень важно для вопроса). Генерация устанавливается как этап предварительной сборки в Visual Studio. Таким образом, каждый раз, когда разработчик (или официальный процесс сборки) запускает сборку, эти классы генерируются, а затем компилируются в проект.

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

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

Есть аргументы или контраргументы?

Я не буду выбирать принятый ответ на данном этапе по причинам, указанным выше.

Сохранение его в системе контроля версий - больше проблем, чем оно того стоит.

Вы должны делать коммит каждый раз, когда делаете сборку, чтобы он имел какое-либо значение.

Обычно мы оставляем сгенерированный код (idl, jaxb и т. Д.) Вне системы управления версиями, где я работаю, и это никогда не было проблемой

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

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

Я бы предпочел иметь более понятный список модификаций, который включает только реальные выполненные обновления, а не автоматически сгенерированные изменения.

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

Посмотрите на это так: вы проверяете свои объектные файлы в системе управления версиями? Сгенерированные исходные файлы являются артефактами сборки, как и объектные файлы, библиотеки и исполняемые файлы. К ним следует относиться одинаково. Многие утверждают, что вам не следует проверять сгенерированные объектные файлы и исполняемые файлы в системе управления версиями. Те же аргументы применимы к сгенерированному источнику.

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

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

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

Я называю принцип СУХОЙ. Если у вас уже есть «исходные файлы» в репозитории, которые используются для генерации этих файлов кода во время сборки, нет необходимости фиксировать один и тот же код «дважды».

Кроме того, таким образом можно предотвратить некоторые проблемы, если, например, генерация кода когда-нибудь прервется.

Нет, по трем причинам.

1. Исходный код - это все необходимое и достаточное для воспроизведения снимка вашего приложения на текущий или предыдущий момент времени - не больше и не меньше. Отчасти это означает, что кто-то несет ответственность за все, что было проверено. Обычно я счастлив быть ответственным за код, который я пишу, но не за код, созданный в результате того, что я пишу.

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

3. Когда он находится в системе контроля версий, я беру на себя ответственность за. находясь там, b. он актуален, и c. он надежно интегрируется со всем остальным. Это включает удаление его, когда я больше не использую его. Чем меньше ответственности, тем лучше.

Я действительно не думаю, что вам стоит их проверять.

Несомненно, любое изменение в сгенерированном коде будет либо шумом - изменениями между средами, либо изменениями в результате чего-то еще - например, изменения в вашей БД. Если сценарии создания вашей БД (или любые другие зависимости) находятся в системе управления версиями, то зачем вам также нужны сгенерированные сценарии?

Общее правило - нет , но если для генерации кода требуется время (из-за доступа к БД, веб-служб и т. Д.), Вы можете сохранить кешированную версию в системе управления версиями и избавить всех от боли.

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

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

Мы также не храним сгенерированный код БД: поскольку он сгенерирован, вы можете получить его по желанию в любой заданной версии из исходных файлов. Сохранение его было бы похоже на сохранение байт-кода или чего-то подобного.

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

Пропусти это.

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

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

Мир боли ждет тех, кто проверяет сгенерированные файлы!

Есть особый случай, когда вы хотите проверить свои сгенерированные файлы: когда вам может потребоваться создать системы, в которых инструменты, используемые для создания других файлов, недоступны. Классическим примером этого, с которым я работаю, является код Lex и Yacc. Поскольку мы разрабатываем систему времени выполнения, которая должна строиться и работать на огромном разнообразии платформ и архитектур, мы можем полагаться только на то, что целевые системы имеют компиляторы C и C ++, а не на инструменты, необходимые для генерации кода лексирования / анализа для определения нашего интерфейса переводчик. Таким образом, когда мы меняем грамматику, мы проверяем сгенерированный код для его анализа.

прибыл немного поздно ... во всяком случае ...

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

Поэтому я бы сказал: не ставьте сгенерированный код под контроль версий, а только генератор и его ввод.

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

В некоторых проектах я добавляю сгенерированный код в систему управления версиями, но это действительно зависит. Моя основная рекомендация заключается в том, что если сгенерированный код является внутренней частью компилятора, я не буду его добавлять. Если сгенерированный код взят из внешнего инструмента, такого как SubSonic в этом случае, я бы добавил if в систему управления версиями. Если вы периодически обновляете компонент, я хочу знать изменения в сгенерированном источнике в случае возникновения ошибок или проблем.

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

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

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

Первый гарантирует, что, когда вы сообщаете клиенту или конечному пользователю, что «ошибка, о которой вы сообщили на прошлой неделе, была исправлена ​​и была добавлена ​​новая функция», они не вернутся через два часа и не скажут «нет, не было». Это также гарантирует, что они не скажут: «Почему он делает X? Мы никогда не просили X».

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

Это означает, что ваш компилятор, библиотеки и т. Д. Также должны быть частью CM.

Итак, теперь отвечу на ваш вопрос: если вы можете сделать все вышеперечисленное, вам не нужно записывать какие-либо промежуточные представления, потому что вы в любом случае гарантированно получите тот же ответ. Если вы не можете сделать все вышеперечисленное, то все ставки отменены, потому что вы никогда не можете гарантировать, что сделаете одно и то же дважды и получите тот же ответ. Так что вы можете также поставить все свои файлы .o под контроль версий.

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

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

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

Правильный ответ - «зависит от обстоятельств». Это зависит от потребностей клиента. Если вы можете откатить код до определенного выпуска и противостоять любому внешнему аудиту без него, то вы все еще не на твердой почве. Как разработчикам мы должны учитывать не только «шум», боль и дисковое пространство, но и тот факт, что нам поручена роль создания интеллектуальной собственности, и это может иметь юридические последствия. Сможете ли вы доказать судье, что вы можете восстановить веб-сайт именно таким, каким его видел клиент два года назад?

Я не предлагаю вам сохранять или не сохранять созданные файлы, каким бы способом вы ни решили, если вы не привлекаете экспертов по предметным вопросам, которые, вероятно, ошибаются.

Мои два цента.

Здесь есть веские аргументы как за, так и против. Для справки, я создаю систему генерации T4 в Visual Studio, и наша готовая опция по умолчанию вызывает регистрацию сгенерированного кода. Вам придется немного усерднее работать, если вы предпочитаете не регистрировать.

Для меня ключевым моментом является изменение сгенерированного вывода, когда обновляется либо ввод, либо сам генератор.

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

Здесь уместно спросить: «Почему вас беспокоят изменения в сгенерированном коде?» (Особенно по сравнению с объектным кодом.) Я считаю, что есть несколько ключевых причин, которые сводятся к текущему состоянию техники, а не к какой-либо внутренней проблеме.

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

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

3. Вы просто не на 100% доверяете выходу вашего генератора от выпуска к выпуску. Инструменты генератора могут принести большую пользу, даже если они не созданы и не поддерживаются в соответствии со строгостью поставщика компилятора. Версия 1.0 могла быть совершенно стабильной для вашего приложения, но, возможно, в версии 1.1 есть несколько ошибок для вашего варианта использования. В качестве альтернативы вы изменяете входные значения и обнаруживаете, что используете новую часть генератора, которую раньше не использовали - возможно, вы удивитесь результатам.

По сути, все это сводится к зрелости инструментов - большинство генераторов кода бизнес-приложений не приблизились к тому уровню, которым были компиляторы или даже инструменты уровня lex / yacc в течение многих лет.

У обеих сторон есть веские и разумные аргументы, и сложно прийти к единому мнению. Системы управления версиями (VCS) отслеживают файлы, которые разработчики помещают в них, и предполагают, что файлы внутри VCS создаются вручную разработчиками, и разработчиков интересует история и изменения между любыми ревизиями файлов. Это предположение уравнивает две концепции: «Я хочу получить этот файл при оформлении заказа». и «Я заинтересован в изменении этого файла».

Теперь аргументы с обеих сторон можно перефразировать так:

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

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

Резюме

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

• git status по умолчанию не должен показывать сгенерированные файлы.
• git commit должен включать сгенерированные файлы как снимки.
• git diff по умолчанию не должен показывать сгенерированные файлы.

PS

Перехватчики Git можно было бы использовать как обходной путь, но было бы здорово, если бы git поддерживал его изначально. gitignoreне соответствует нашему требованию, поскольку игнорируемые файлы не попадают в VCS.enter code here

Я бы поспорил. Если вы используете процесс непрерывной интеграции, который проверяет код, изменяет номер сборки, строит программное обеспечение, а затем тестирует его, то проще и проще иметь этот код как часть вашего репозитория.

Кроме того, это неотъемлемая часть каждого «снимка» вашего репозитория программного обеспечения. Если это часть программного обеспечения, то оно должно быть частью репозитория.

Я бы сказал, что да, вы хотите поместить его в систему контроля версий. С точки зрения управления конфигурацией ВСЕ, что используется для создания сборки программного обеспечения, требует контроля, чтобы его можно было воссоздать. Я понимаю, что сгенерированный код можно легко воссоздать, но можно привести аргумент, что это не одно и то же, поскольку даты / временные метки будут разными в двух сборках. В некоторых областях, таких как правительство, они часто требуют, чтобы это было сделано.

Как правило, сгенерированный код не нужно хранить в системе контроля версий, потому что историю изменений этого кода можно отследить по истории изменений кода, который его сгенерировал!

Однако похоже, что OP использует сгенерированный код в качестве уровня доступа к данным приложения вместо того, чтобы писать его вручную. В этом случае я бы изменил процесс сборки и передал код в систему управления версиями, потому что это критический компонент кода времени выполнения. Это также устраняет зависимость от инструмента генерации кода из процесса сборки в случае, если разработчикам нужно использовать разные версии инструмента для разных ветвей.

Кажется, что код нужно сгенерировать только один раз вместо каждой сборки. Когда разработчику необходимо добавить / удалить / изменить способ доступа объекта к базе данных, код должен быть сгенерирован снова, как при внесении изменений вручную. Это ускоряет процесс сборки, позволяет вручную оптимизировать уровень доступа к данным, а история уровня доступа к данным сохраняется простым способом.

Я (к сожалению) заканчиваю тем, что помещаю много производных источников под контроль версий, потому что я работаю удаленно с людьми, которые либо не беспокоятся о настройке надлежащей среды сборки, либо не имеют навыков, чтобы настроить ее так, чтобы производные источники построены точно. (А когда дело доходит до автоинструментов Gnu, я сам один из таких людей! Я не могу работать с тремя разными системами, каждая из которых работает с разными версиями автоинструментов - и только с этой версией.)

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

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

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

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

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

Я бы оставил сгенерированные файлы вне дерева исходных текстов, но поместил бы их в отдельное дерево сборки.

например рабочий процесс

1. проверка / выход / изменение / слияние исходного кода в обычном режиме (без каких-либо сгенерированных файлов)
2. В соответствующих случаях извлекайте дерево исходных текстов в чистое дерево сборки.
3. После сборки проверьте все «важные» файлы («реальные» исходные файлы, исполняемые файлы + сгенерированный исходный файл), которые должны присутствовать для целей аудита / регулирования. Это дает вам историю всего соответствующего сгенерированного кода + исполняемых файлов + чего угодно, с приращениями времени, которые связаны с выпусками / тестовыми снимками и т. Д. И не связаны с повседневной разработкой.

В Subversion / Mercurial / Git / и т.д., вероятно, есть хорошие способы связать вместе историю реальных исходных файлов в обоих местах.

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

ОБНОВЛЕНИЕ: я задал этот вопрос, так как действительно верил, что есть один окончательный ответ. Глядя на все ответы, я могу с большой долей уверенности сказать, что такого ответа нет. Решение должно приниматься на основании более чем одного параметра. Прочтение других ответов может дать очень хорошее представление о типах вопросов, которые вы должны задать себе, когда вам нужно решить эту проблему.