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

Ответ 1

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

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

Как правило, мы оставляем сгенерированный код (idl, jaxb stuff и т.д.) вне контроля исходного кода, где я работаю, и это никогда не было проблемой.

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

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

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

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

Ответ 19

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

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

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

Ответ 20

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

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

Ответ 21

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

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

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

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

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

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

Ответ 22

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

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

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

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

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

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

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

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

Ответ 23

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

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

• checkin/out/modify/merge source обычно (без каких-либо сгенерированных файлов)
• В соответствующих случаях проверьте исходное дерево в дереве чистой сборки
• После сборки проверьте все "важные" файлы ( "реальные" исходные файлы, исполняемые файлы + сгенерированный исходный файл), которые должны присутствовать для целей аудита/регулирования. Это дает вам историю всех соответствующих сгенерированных кодов + исполняемых файлов + что угодно, при добавлении времени, связанных с выпуском/тестированием моментальных снимков и т.д. И развязанных из повседневной разработки.

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

Ответ 24

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

Ответ 25

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

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

Ответ 26

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

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

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

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

Резюме

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

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

PS

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

Ответ 27

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

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

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