Стоит ли помещать все проекты в один ствол?

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

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

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

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

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

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

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


svn project-organization
person Victor Rodrigues    schedule 28.04.2009    source источник

Ответы (4)


arrow_upward
4
arrow_downward

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

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

  • теги
  • ветви
  • багажник

И тогда у нас есть каждый проект как подкаталог тех.

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

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

Проблемы с svn:externals:

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

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

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

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

person Brian R. Bondy    schedule 28.04.2009
comment
Я согласен с этим. Наличие проектов в отдельных репозиториях затрудняет совместное использование кода и объединение изменений между продуктами, если это необходимо. Работать в отдельных ветвях проекта чище, потому что вы можете работать независимо, но при этом отправлять изменения вниз по стволу. - person Nick Haddad; 28.04.2009
comment
Согласованный; у нас есть отдельный репо для каждого проекта, и это вызывает проблемы. Мы экспериментировали с несколькими проектами на репозиторий, и это сработало лучше; главное, что мешает нам перейти на это навсегда, — это разрешения. (commit-access-control.pl не очень настраиваемый, в то время как вы можете управлять отдельными репозиториями, используя модуль LDAP с apache или подобным. Мы также можем выборочно предоставлять только определенные репозитории для внешнего доступа. Вероятно, есть более новый/лучший способ делать все это, но пока что мы используем отдельные репозитории.) - person leander; 29.04.2009
comment
Да, я использую apache и настраиваю его таким образом, об этом есть поток на SO stackoverflow.com/questions/484499/ - person Brian R. Bondy; 29.04.2009
comment
Вам не нужно помещать проекты в их собственный репозиторий, чтобы создавать собственные версии ствола и веток. Например. Фонд Apache хранит все свои проекты в одном репозитории, но у каждого есть свой ствол и ветки. - person Bert Huijben; 29.04.2009

arrow_upward
1
arrow_downward

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

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

person crashmstr    schedule 28.04.2009

arrow_upward
1
arrow_downward

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

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

Так почему бы вам не использовать общие теги (с вехами в качестве имен) для всех ваших проектов, чтобы обеспечить одинаковую кодовую базу и скрипт сборки, который может автоматически проверять проекты (транки)? Это больше работы, но, как обычно в ООП (капсулировании), я бы также предпочел разделить проекты на отдельные каталоги 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 и в предыдущем посте.

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

Чао, Крис

person 3DH    schedule 28.04.2009
comment
Мы используем примерно такой же макет. Мы используем проекты (внутренние), продукты (доставленные) и библиотеки (повторно используемые компоненты) в качестве имен верхнего уровня. - person Bert Huijben; 29.04.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person Wim Coenen    schedule 28.04.2009