где хранить снимки сборки в svn

Question

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

ПРИМЕЧАНИЕ: Практический результат этогоявляется то, что для любого выпущенного вывода сборки, мне нужно бесконечно заархивировать его неизменную копию.(Например, если мы строим из r993, r1014, r1205 и r1293 нашего дерева исходников, мне нужно сохранить один выход для каждой сборки.)

Для нас естественно использовать Subversion, потому что у нас есть серверБег.Неестественно то, куда помещать выходные данные сборки.

1. Проверка в области дерева исходных текстов -> не хорошо, потому что это усложняет обновления / слияния / и т.д..

2. Создать специальную область в хранилище, связанную с исходным деревом например:

   project-foo/
     branches/
     tags/
     trunk/
     build/        <-- released executables go here
                   (along with metadata containing source references)
   

   Нам действительно не нужны ветви илитеги для исполняемого вывода;Мне просто нужно место, которое является неизменным снимком, на который я могу сослаться (в случае SVN, путем и rev #)

3. Создать специальную область в репозитории, слабо связаннуюс исходным деревом например:

   project-foo/
     branches/
     tags/
     trunk/
   project-foo-build/          <-- released executables go into a subdir:
     branches/
     tags/
     trunk/
   

4. Использовать другую программу, а не SVN. ???Что бы это ни было, оно должно поддерживать идеи

   • неизменных данных
   • метаданных, связанных с данными
   • нескольких версий одного и того же вида вещей (например,исполняемый файл build для проекта foo)

Есть предложения?

Я склоняюсь к идее № 2, но хотел бы отступить назад и лучше понять различные преимущества / недостатки.

---

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

Answer 1

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

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

Answer 2

Вы можете создать, svn add двоичные файлы для вашей рабочей копии, а затем пометить непосредственно из вашей рабочей копии :

build.bat
svn add bin\*
svn cp . http://example.com/svn/myproject/tags/x.y -m "tagging release x.y"
svn revert -R .

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

Обратите внимание на svn revert в конце. Это необходимо, потому что svn status будет по-прежнему отображать изменения, сделанные svn add. Вам не нужны эти изменения в багажнике.

Answer 3

Некоторые из ваших опций работали бы просто отлично, но я бы проголосовал за # 4.

Моя компания также создает и выпускает встроенные пакеты SW, и нам требуется хранение фактических двоичных файлов, которые мы поставляем (вместе со сборкойдокументация, различные форматы выходных файлов и т. д.) в дополнение к маркировке ревизии SW в репозитории.

Я согласен с ответом Грега Хьюгилла относительно размещения их на файловом сервере в отдельном каталоге.Если, с другой стороны, вы ищете более полный инструмент SCM, Redmine - отличный вариант с открытым исходным кодом.Redmine обеспечивает привязки SVN (или Hg, Git и т. Д.), Отслеживание проблем, управление файлами и так далее.Это не просто хранилище файлов, а более полный инструмент SCM.

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

Answer 4

Как вы говорите, неестественно использовать SVN для продуктов сборки, потому что хорошей практикой является использование только исходного кода в вашем хранилище.Лучше назовите выходные данные сборки без неоднозначностей (project-branch-revision), названных вашим процессом сборки, и архивируйте выходные данные сборки классическим способом (файловый сервер).