Хорошая идея поместить все проекты в один ствол?

Question

Мы понимаем, что стандартная и обычно рекомендуемая организация хранилища SVN, в случае нескольких проектов, выглядит примерно так:

root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...

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

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

Итак, один из членов команды предложил что-то, что, как мы все думаем, могло бы стать лучшим решением: поместите все проекты в один ствол.

Сначала мы распознали некоторые проблемы с этим подходом, но в целом мы согласны, что эти проблемы основаны на гипотетических ситуациях, которые, вероятно, мы никогда бы не испытали.

Видите ли вы некоторые серьезные проблемы, которые могут возникнуть у нас с этим решением?

Answer 1

Мы делаем это в нашей компании и добились большого успеха.

У нас есть 3 каталога верхнего уровня:

• метка
• филиалы
• багажник

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

Мы по-прежнему разветвляемся на уровне проекта и по-прежнему используем svn: externals. Но если бы у нас было меньшее исходное дерево, мы бы разветвлялись на уровне ствола и не использовали svn: extenrals.

Приятно иметь возможность иметь ствол всех проектов в одном месте. Вы можете сделать резервную копию, вы можете проверить все это, и у вас есть все самые последние вещи вместе. Вы не потеряете ни единого местоположения для всех веток, ни единого местоположения для всех тегов, потому что все они находятся в подкаталогах / branch / projectX и / tags / projectX

Проблемы с SVN: внешние:

Если ваши проекты не являются ОГРОМНО ОГРОМНЫМИ, вы можете просто разветвлять весь ствол каждый раз и избегать всех проблем с svn: externals.

Проблема с svn: externals в том, что когда вы создаете ветку, она автоматически не создает ветку для каждого из svn: externals для вас. Это проблема, потому что со временем все ваши старые ветки не смогут скомпилироваться, так как ваш ствол будет обновляться. Другая проблема заключается в том, что если вы исправляете в какой-либо ветке svn: external, все остальные ваши ветки ломаются.

Другая проблема с svn externals заключается в том, что когда вы делаете svn: log на корневом уровне, вы не видите никаких изменений от svn externals.

Надеюсь, однажды svn externals будет исправлено для решения вышеуказанных проблем, но до этого дня ветвление и svn: externals - абсолютный кошмар.

Answer 2

Видите ли вы некоторые серьезные проблемы, которые мы может иметь с этим решением?

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

  Это означает, что в обозримом будущем весь репозиторий должен поместиться на одном диске (или в пуле хранения). Аналогичные соображения применимы и к другим ресурсам сервера, таким как пропускная способность сетевого и дискового ввода-вывода.

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

• Ваше решение работает, только если вам не нужно ограничивать права на чтение / запись для каждого пользователя

  Если вам нужно дать разрешение на чтение / запись для projectA, вам фактически нужно будет дать разрешение для / trunk / projectA и / branch1 / projectA, и / branch2 / projectA и т. Д.

  Затем ветвление превращается в тяжеловесный процесс, требующий много настроек разрешения. Попрощайтесь с функциональными ветками .

Answer 3

для "помещения всех проектов в один ствол":

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

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

Но: собрать кучу маленьких библиотек и приложений в общий каталог в одной и той же соединительной линии нет проблем (см. «Приложения» и «инструменты» в моем примере ниже) - так что, возможно, «маленькие проекты» могут остаться в общем / большой багажник.

Вот в качестве примера моя структура каталогов SVN:

/projects/
/projects/CustomerA/
/projects/CustomerA/ProjectX/
/projects/CustomerA/ProjectX/trunk/
/projects/CustomerA/ProjectX/tags/
/projects/CustomerA/ProjectX/branches/
/thirdparty/
/thirdparty/ExtLibY/
/thirdparty/ExtLibZ/
/tools/
/tools/trunk/
/tools/tags/
/tools/branches/
/apps/
/apps/trunk/
/apps/tags/
/apps/branches/

Таким образом, все внешние компоненты хранятся в / thirdparty /, а все внутренние компоненты (проекты, инструменты, приложения) имеют подкаталоги:

/trunk/
/tags/    
/branches/

... как советовали в книге Subversion и в предыдущем посте.

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

чао, Chris

Answer 4

То, что вы сделали, - это то, что я настроил в своей компании, и это также упоминается как «очень распространенная схема» в теме svnbook, Стратегии развертывания репозитория .

В этом нет ничего плохого.