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


106

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

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

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

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

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


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

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


1
Возможно, вас заинтересует аналогичный вопрос: stackoverflow.com/questions/739391/…
mouviciel

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

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

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

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

Ответы:


48

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

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

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


43
Я не согласен с тем, что «вы должны делать коммит каждый раз, когда строите». Это не должно вызывать дополнительной фиксации, потому что единственное, что должно повлиять на фиксацию, - это изменение кода, которое, следовательно, изменяет сгенерированный источник. Таким образом, вы должны фиксировать сгенерированный код только тогда, когда вы уже вносите изменения в источник сгенерированного кода.
JaredPar

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

Различные инструменты могут генерировать разные источники (по крайней мере, они могут отличаться комментариями или форматированием кода). Например, Idea добавляет комментарий «сгенерированный идеей», а Eclipse - нет.
Петр Гладких

1
Мнения разделились, отметив это как ответ, вы передали бы неверное сообщение.
Espresso

34

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


18
Это не преимущество - поскольку созданный код проверен, у вас уже есть «все, что вы пишете», доступное для будущих разработчиков.
Шейн С. Мейсон

13
@Shane, я категорически не согласен. Наличие кода, который его создал, не значит иметь код. Любые дополнительные шаги, которые необходимо включить для генерации, вызывают дополнительное раздражение при отслеживании ошибки. Гораздо проще просмотреть историю кода, чем проверить N версий файла и повторно сгенерировать N версий сгенерированного кода.
JaredPar

10
Иногда полезно иметь сгенерированные файлы в системе контроля версий. Например, если вы обновляете компонент, в данном случае SubSonic, вы можете легко обнаружить изменения в сгенерированном источнике. Это может быть полезно для отслеживания ошибок и проблем. Я бы не стал добавлять весь сгенерированный код в систему управления версиями. Иногда бывает очень полезно. Большинство систем управления версиями позволят вам выполнить различие, чтобы увидеть, действительно ли файлы изменились, хотя это может быть больше ручной процесс, если вам нужно вручную вернуть файлы, даже если единственное изменение - это временная метка.
Райан

18
По этой логике вы также должны проверять свои скомпилированные объектные файлы, библиотеки и исполняемые файлы.
Лоуренс Гонсалвес,

9
Какой генератор кода вы используете, когда «исходный язык не имеет смысла»? Что касается отслеживания того, какие версии ваших инструментов вы используете для создания каждой версии кода, вам уже нужно решить эту проблему для всей цепочки инструментов. В конце концов, как вы ожидаете перенести ошибку в более старую версию вашего продукта, если вы не знаете, какую версию компилятора и компоновщика вы использовали тогда? Генератор кода ничем не отличается от вашего компилятора C ++ / Java / C #. Тот факт, что вы можете прочитать его вывод, несущественен: его ввод является источником.
Лоуренс Гонсалвес,

31

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

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

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


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

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

+1 Я хочу отвечать только за то, какой код я пишу, а не за какой-то код, который был сгенерирован каким-то набором инструментов, у которого в то время могли быть проблемы, которые сейчас невозможно скопировать (но кто-то может потратить много времени на попытки)
dkretz

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

25

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

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

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


20

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


1
К вашему сведению, я поделился скриптом для этого сравнения здесь: stackoverflow.com/a/16754923/105137
kostmo

17

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

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


15

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

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

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

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


14

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

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


8

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

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

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


6

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

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


5

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

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

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

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


4

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


2
Подобные комментарии относятся к файлам, созданным autoconf / automake; большинство людей проверяют свои файлы ./configure и Makefile.in, даже если они сгенерированы - большинству пользователей (и многим разработчикам) не нужно их перестраивать, и, проверяя эти файлы, вам не нужно устанавливать автоинструменты строить.
Stobor

1
Да, мы храним наш скрипт конфигурации и наши сгенерированные зависимости Make в системе контроля версий.
Фил Миллер

4

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

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

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

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


3

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

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


3

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

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

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

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

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

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


2

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

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

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


"это означает не только ваш исходный код, но и среду сборки, вашу IDE, возможно, даже другие библиотеки, генераторы или прочее" \ n Это все, что я бы проверил. Если вы собираете свой компилятор из исходного кода на каждой машине разработчика как часть той же сборки, что и ваши приложения (например, вы набираете «make» один раз), проверьте исходный код. Если нет, то проверьте двоичные файлы
KeyserSoze

2

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

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

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


Вы делаете интересный момент и не принимаете отрицательный ответ на свой счет, просто для практических целей в часто быстро меняющихся средах разработки это просто непрактично. Почему в любом случае автоматически сгенерированный код будет нести какие-либо данные, относящиеся к контенту или IP? Я бы предположил, что клиенты в целом не смогут понять последствия автоматически сгенерированного кода с контролем исходного кода и, вероятно, вообще не должны предлагать эту опцию. ИМХО это слишком много накладных расходов и затрат, чтобы заниматься гипотетической и маловероятной правовой ситуацией.
Крис Хэлкроу

В сфере страхования, в которой я сейчас работаю, наш (очень крупный) клиент хранит ВСЕ как минимум 10 лет. Мы создаем сложные инструменты для создания служб WCF. Клиенты сохраняют сгенерированный код, шаблоны и все такое. Но это мой клиент. Думаю, вы упустили тот момент, о котором я говорил: «Это зависит от потребностей клиента» и «как бы вы ни решили, если вы не привлекаете экспертов по предметным вопросам к принятию решения, вы, вероятно, ошибаетесь». Если почему-то это плохой ответ или вам становится легче, ставя -1, рад, что помог. Обратитесь к «womp» в комментарии над моим ответом.
Джеймс Флеминг,

2

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

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

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

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

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

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

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

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


2

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

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

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

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

Резюме

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

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

PS

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


1

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

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


5
Я люблю ездить на -1. Если вы не согласны, не голосуйте - проголосуйте за другие ответы. Сохраните отрицательные голоса для неправильного ответа. Это субъективный вопрос.
womp

1

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


2
Вы регистрируете свои объектные файлы (.o)?
KeyserSoze

1

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

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

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


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

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

1

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

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

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


1

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


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

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

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

1

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

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

1
А сам генератор кода не находится в системе контроля версий, потому что ...?
Джеффри Хантин,

@ Джеффри: Я никогда не говорил, что генератор кода не находится в системе контроля версий.
Джо Энос,

Я знаю, я просто дразню. :-) Я обнаружил, что многие генераторы кода на основе CodeDom любят выводить свои данные в случайном порядке, поэтому для воспроизводимости (и, следовательно, возможности легко определить, изменяется ли сгенерированный код от запуска к запуску), я ' написал подпрограмму, которая сортирует содержимое CodeCompileUnitв каноническом порядке.
Джеффри Хантин, 07

0

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

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

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

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


0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.