конкретная схема репо Subversion в компании

Question

Сначала я объясню историю использования Subversion в нашей компании. Мы начали использовать Subversion около 3 лет назад. Мы используем его вместе с TortoiseSVN в качестве клиента.

У нас есть 3 хранилища с совершенно разными проектами, которые не имеют ничего общего.

Но в 1 репозитории у нас есть около шести продуктов / проектов, которые используют общие библиотеки DLL (для архивирования, XML, базовых типов и т. Д.) У нас есть около 20 из этих общих DLL (которые все еще обновляются).

Итак, эти 20 Common Dll находятся в багажнике вместе с шестью проектами, которым они нужны.

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

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

Таким образом, мы создаем папку trunk / branch / tags для каждого проекта и делаем svn-копию только dll, необходимой для этого проекта.

Ситуация:

До:

  -branches
  -tags
  -trunk
      -Common DLL 1
      -Common DLL 2
      -Common DLL 3
      -Common DLL 4
      -Common DLL 5
      -Project 1
      -Project 2
      -Project 3

Теперь

  -Projects
      -Project1
          -branches
          -tags
          -trunk
              -Common DLL 1
              -Common DLL 2
              -Project1
      -Project2
          -branches
          -tags
          -trunk
              -Common DLL 2
              -Common DLL 3
              -Common DLL 4
              -Project2

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

ОДНАКО: у нас много проблем с объединением этих Common Dll. С последней версией TortoiseSVN у нас постоянно возникают «конфликты деревьев». Также много проблем со слиянием (иногда возвращаясь назад больше месяца и не помня, что действительно изменилось).

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

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

Можем ли мы сохранить эту структуру репо или изменить ее. Что лучше поместить все Common Dll в другой репо, а затем использовать внешние?

ТНХ

Answer 1

Что лучше поместить все Common Dll в другой репо, а затем использовать внешние?

Не обязательно «еще один репо», но вы должны определенно относиться к нему как к проекту, который стоит сам по себе. Ваш макет должен выглядеть так:

  -Project1
      -trunk
      -branches
      -tags
  -Project2
      -trunk
      -branches
      -tags
  -CommonDLL1
      -trunk
      -branches
      -tags
  -CommonDLL2
      -trunk
      -branches
      -tags
   -...

Тогда Project1/trunk, вероятно, будет иметь свойство svn:externals с таким содержанием:

-r148 ^/CommonDLL1/trunk CommonDLL1
-r157 ^/CommonDLL2/trunk CommonDLL2

Это свойство заставляет Subversion автоматически создавать папки CommonDLL1 и CommonDLL2 внутри вашей рабочей копии Project1/trunk всякий раз, когда вы делаете заказ или обновляете.

Обратите внимание, что определение внешнего вида содержит номер редакции. Это гарантирует, что , если вы измените что-либо в CommonDLL1, это не повлияет на Project1, пока вы явно не измените номер редакции в определении внешних элементов. Это особенно важно для неизменности тегов вашего проекта.

У этого подхода есть некоторые недостатки, с которыми вам приходится сталкиваться:

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

• Ваш сервер непрерывной интеграции не обнаружит автоматически, что последняя Project1/trunk больше не соответствует последней CommonDLL1/trunk. Об этом вы узнаете только при изменении номера ревизии в определении внешнего кода.

  1036 **

Answer 2

Тенденция состоит в том, чтобы разбить вещи на (разумные) логические, отдельно стоящие единицы. Интересно, что Git DVCS повысила осведомленность: люди, желающие оформить заказ просто / trunk / project, столкнулись с невозможностью сделать это, и общий ответ заключался в том, чтобы расколоть проекты (считающиеся автономными единицами) в собственное репо.

Несмотря на то, что такие мелкозернистые пакеты (подход "/ project / trunk") требуют немного больше работы, независимость каждого компонента в конечном итоге отыгрывается. Разделение проектов и кода заставляет людей больше думать об API и взаимодействии. Другими словами, возможно, вам больше не нужно будет знать всю картину целиком, и вы сможете сосредоточиться только на нескольких компонентах.

См. Xorg, который использует эту схему разделенных репозиториев (в том смысле, что у каждого есть собственный мастер / ствол).

Для вас это означает: ваше состояние "сейчас" соответствует этому самому описанию. Жаль, однако, что TSVN не может справиться с состоянием хранилища; плохое взаимодействие с инструментом в сочетании с проектными решениями, принятыми SVN несколько лет назад.

Answer 3

Я думаю, что второй подход намного лучше, чем первый.Но немного сложно управлять в первую очередь.