Если я храню сгенерированный код в управлении исходным кодом

Вот еще один пример, который я нашел:

https://github.com/jspears/bobamo

Я лично еще не использовал его, но когда я плохо сообщать

96
задан thatismatt 8 June 2009 в 14:29
поделиться

25 ответов

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

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

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

49
ответ дан 24 November 2019 в 05:33
поделиться

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

0
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

1
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

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

0
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

1
ответ дан 24 November 2019 в 05:33
поделиться

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

1
ответ дан 24 November 2019 в 05:33
поделиться

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

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

1
ответ дан 24 November 2019 в 05:33
поделиться

It really depends. Ultimately, the goal is to be able to reproduce what you had if need be. If you are able to regenerate your binaries exactly, there is no need to store them. but you need to remember that in order to recreate your stuff you will probably need your exact configuration you did it with in the first place, and that not only means your source code, but also your build environment, your IDE, maybe even other libraries, generators or stuff, in the exact configuration (versions) you have used.

I have run into trouble in projects were we upgraded our build environment to newer versions or even to another vendors', where we were unable to recreate the exact binaries we had before. This is a real pain when the binaries to be deplyed depend on a kind of hash, especially in secured environment, and the recreated files somehow differ because of compiler upgrades or whatever.

So, would you store generated code: I would say no. The binaries or deliverables that are released, including the tools that you reproduced them with I would store. And then, there is no need to store them in source control, just make a good backup of those files.

2
ответ дан 24 November 2019 в 05:33
поделиться

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

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

6
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

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

13
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

8
ответ дан 24 November 2019 в 05:33
поделиться

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

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

14
ответ дан 24 November 2019 в 05:33
поделиться

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

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

17
ответ дан 24 November 2019 в 05:33
поделиться

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

28
ответ дан 24 November 2019 в 05:33
поделиться

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

20
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

25
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

31
ответ дан 24 November 2019 в 05:33
поделиться

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

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

3
ответ дан 24 November 2019 в 05:33
поделиться

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

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

There is a special case where you want to check in your generated files: when you may need to build on systems where tools used to generate the other files aren't available. The classic example of this, and one I work with, is Lex and Yacc code. Because we develop a runtime system that has to build and run on a huge variety of platforms and architectures, we can only rely on target systems to have C and C++ compilers, not the tools necessary to generate the lexing/parsing code for our interface definition translator. Thus, when we change our grammars, we check in the generated code to parse it.

4
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

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

4
ответ дан 24 November 2019 в 05:33
поделиться

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

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

0
ответ дан 24 November 2019 в 05:33
поделиться

Оставьте это.

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

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

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

5
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

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

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

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

2
ответ дан 24 November 2019 в 05:33
поделиться

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

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

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

2
ответ дан 24 November 2019 в 05:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: