Хорошая идея состоит в том, чтобы поместить все проекты в ту же соединительную линию?

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

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

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

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

• tags
• branch
• trunk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но до этого дня ветвление и svn: externals - абсолютный кошмар.

но до этого дня ветвление и svn: externals - абсолютный кошмар.

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

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

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

Но: собрать кучу маленьких библиотек и приложений в общий каталог в одной и той же магистрали нет проблем. (см. «приложения» и «инструменты» Chris

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

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

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

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

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

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

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