Один репозиторий SVN или много? - PullRequest
103 голосов
/ 31 октября 2008

Если у вас есть несколько несвязанных проектов, будет ли хорошей идеей поместить их в один и тот же репозиторий?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

или вы бы создали новые репозитории для каждого?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

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

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

Ответы [ 13 ]

2 голосов
/ 31 октября 2008

Если вы планируете использовать такой инструмент, как trac, который интегрируется с SVN, или использовать его, имеет смысл использовать по одному репо на проект.

1 голос
/ 01 июня 2010

Подобно тому, как mlambie использует один репозиторий, но пошёл немного дальше со структурой папок, чтобы легко масштабировать до определенного типа проектов - веб-html-проекты против cs (C #) или sql (сценарии создания / выполнения SQL) против .xyz (специфичные для домена языки, такие как afl (язык формулы AmiBroker) или ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Обратите внимание, у меня есть ствол, живущий в ветвях, поскольку я рассматриваю его как ветвь по умолчанию. Единственная боль иногда возникает, когда вы хотите быстро создать другой проект, вам нужно создать структуру ProjectName / branch | tags. Я использую настройки приложения просто как место для хранения определенных файлов настроек приложений в репозитории, чтобы их можно было легко обменивать с другими (и заменяю ClientName на VendorName и ProjectName на AppName в этой структуре папок; а теги ветвей | могут быть полезны для пометки настроек в различных основных версии продуктов вендора тоже).

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

1 голос
/ 31 октября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...