Лучшая настройка для продвижения кода и ветвления функции в Subversion?

Question

Мы - команда из 4 человек и далеко не вдали от нашей зоны комфорта в течение нескольких лет, но мы развиваемся и хотели бы догнать время. Мне было поручено найти лучший способ реализации Continuous Integration (автоматические сборки, ветвление для обслуживания кода и новые функции и т. Д.). Мы смотрим на переход от SourceSafe 2005 к Subversion для управления нашим контролем версий. Из того, что я читал, Subversion - гораздо лучший выбор для продвижения кода, филиалов и объединения филиалов. Мы, вероятно, использовать следующие продукты:

• VisualSVN сервер
• TortoiseSVN (для интеграции с помощью Проводника Windows)
• VisualSVN (для интеграции с Visual Studio 2005)
• SVNVB6 (для интеграции с Visual Basic 6)
• FinalBuilder

Что такое лучший способ организовать хранилище для продвижения коды и функций ветвление? Вот пример нашей нынешней структуры SourceSafe:

• корня
  • Visual Studio 2005 проекты
    • Projectname
      • файл Solution, файлы проекта, и код файлов здесь
      • \ bin
        • \ Release
          • скомпилированных двоичных файлов релиз здесь
  • Visual Basic 6 проектов
    • ProjectName
      • файлы проекта и код файлов здесь
      • откомпилированном (.dll, .exe, .ocx) здесь
  • Документация
    • Документация файлы здесь

Должны ли мы структурироваться так?

• корень
  • ветви (каждая из разветвленных ствола)
    • Development.FeatureA
    • Development.FeatureB
    • Тест (встроенный каждую ночь с FinalBuilder ???)
    • Производство (Встроенный ночной с FinalBuilder ???)
    • Production.BugFixA (Reverse интегрировать в производственное отделение, отделение испытаний, и багажник ???)
  • теги
    • Development.v1 (помеченной после каждой успешной сборки)
    • Development.v2
    • Development.v3
    • Test.v1
    • Test.v2
    • Test.v3
    • Production.v1
    • Production.v2
    • Production.v3
  • Ствол (код развития - Встроенный еженощно с FinalBuilder)
    • Визуальная Studion 2005 Проекты
      • Projectname
        • Файл решения
        • ProjectName
          • файлы проекта и файлы кода здесь
    • Visual Basic 6 проектов
      • ProjectName
        • файлы проекта и код файлов здесь

Поскольку большая часть нашего программного обеспечения является еще COM (VB6) и должен быть зарегистрирован (с помощью regsvr32), должны быть бинарниками контроля версий? Как мы должны обрабатывать регистрацию/отмена регистрации компонентов, когда нам нужно работать с разными ветвями (возможно, с другой совместимостью COM)?

Мы находимся вдали от границы?

Answer 1

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

/Projects 
    /CashCowProject 
    /branches 
    /tags 
    /trunk 
     /vs 
     /doc 

Это означает, что трекер инструменты можно посмотреть на http://svn/Projects/CashCowProject и видеть все действия на том, что проект, и не будет заниматься никаким другим проектом. Кроме того, это заставляет вас контролировать ссылки между проектами, а это значит, что ваши проекты на высшем уровне не будут меняться без записи в туловище.

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

Сохранение двоичных файлов библиотеки в SVN в порядке. Можете рассмотреть отдельный репозиторий для этого, хотя мы этого не делаем.

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

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