Вы используете «производные» файлы?

Question

Использование онлайн-интерфейсов для системы контроля версий - отличный способ опубликовать местоположение для самых последних версий кода. Например, у меня есть пакет LaTeX здесь (который выпущен CTAN всякий раз, когда изменения будут проверены на самом деле работает):

http://github.com/wspr/pstool/tree/master

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

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

Является ли это извращением контроля версий?

---

@Jon Limjap поднял хороший момент:

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

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

С другой стороны, @Madir «s комментарий, что:

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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