Файлы проекта в репозитории

Question

Общепринятой практикой является сохранение файлов проекта (т. Е. Файлов других файлов исходного кода) в репозитории управления версиями?

Кроме того, эти файлы регулярно проверяются/выходят?

Я всегда представлял репозиторий SCC как «чистый» только с файлами исходного кода.

Как вы управляете файлами без исходного кода в репозитории?

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

Answer 1

Я думаю, что общее правило заключается в том, что минимальный объем данных, необходимых для компиляции и запуска проекта, должен быть включен. Это включает в себя искусство (или другие основные файлы данных) и любые скрипты сборки. В случае проекта autotools это обычно означает configure.ac. В проекте Visual Studio это означает файл проекта Visual Studio. Но вы не включаете ничего, что может быть автоматически сгенерировано из остальных, например скрипт «configure», если configure.ac уже существует.

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

Answer 2

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

Как отметил Сидиус, большинство инструментов SCM имеют возможность отмечать не исходные файлы как двоичные. Большинство современных инструментов автоматического обнаружения, не открытым текстом файлов и CVS это:

cvs add -kb filenames 

Answer 3

Вы должны держать все, что вам нужно построить проект в хранилище.

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

Конечный продукт не должен быть сохранен, поскольку он перестроен из источника.

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

Answer 4

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

Answer 5

Один из моих любимых проектов - небольшое кросс-платформенное приложение для Windows, Mac OSX и Linux. Я использую wxWidgets как фреймворк и Kdevelop на Linux, XCode на Mac OSX и Dev-Cpp на Windows в качестве IDE. Файлы проекта для каждой из этих IDE отлично управляемы с помощью CVS и SVN. Я сохраняю файлы проекта в репо. Всякий раз, когда мне приходится перестраивать среду разработки на любой из целевых платформ, все, что мне нужно сделать, это установить IDE и проверить последние CVS.

Answer 6

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

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

Answer 7

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