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

Question

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

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

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

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

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

---

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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