Должен ли я хранить сгенерированный код в системе контроля версий

Question

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

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

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

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

Есть аргументы или встречные аргументы?

---

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

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

Answer 1

Оставь это.

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Краткое описание

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

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

PS

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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