Номер ревизии Subversion для нескольких проектов

Question

При использовании Subversion (svn) для управления источником с несколькими проектами я заметил, что номер версии увеличивается во всех каталогах моих проектов. Для того, чтобы проиллюстрировать мой макет СВН (с использованием фиктивных имен проекта):

 
    /NinjaProg/branches 
       /tags 
       /trunk 
    /StealthApp/branches 
       /tags 
       /trunk 
    /SnailApp/branches 
      /tags 
      /trunk 

Когда я выполнить обязательства по стволу программе Ninja, скажем, я понимаю, что он был обновлен до ревизии 7. На следующий день, скажем, что я внес небольшое изменение в приложение Stealth, и оно возвращается в качестве пересмотра 8.

Вопрос заключается в следующем: При использовании нескольких проектов с одним сервером Subversion общепринятой практикой является ревизия не связанных проектов увеличение числа по всем проектам? Или я делаю это неправильно и должен создавать отдельные репозитории для каждого проекта? Или это совсем другое?

EDIT: Я задержался в маркировки ответ, потому что стало ясно, что есть причины для обоих подходов, и даже несмотря на этот вопрос пришел первым, я хотел бы указать на некоторые другие вопросы, которые в конечном счете, попросив тот же вопрос:

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

Answer 1

Я удивлен, что не упомянул, что это обсуждается в «Управление версиями» с помощью Subversion, которое доступно бесплатно в Интернете, here.

Я прочитал эту проблему некоторое время назад, и это действительно похоже на вопрос личного выбора, есть хорошее сообщение в блоге по теме here. EDIT: Поскольку блог, кажется, не работает, (archived version here), вот некоторые из того, что должен был сказать Марк Пиппард по этому вопросу.

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

1. Упрощенное администрирование. Один набор перехватов для развертывания. Один репозиторий для резервного копирования. и т.д.
2. Отделение/этикетка гибкость. При использовании кода в одном репозитории упрощается создание ветки или тега с участием нескольких проектов.
3. Переместить код легко. Возможно, вы хотите взять раздел кода из одного проекта и использовать его в другом или превратить его в библиотеку для нескольких проектов. Легко перемещать код внутри одного репозитория и сохранять историю кода в процессе.

Вот некоторые из недостатков подхода единого хранилища, преимущества подхода множественного репозитория.

1. Размер. Возможно, было бы легче иметь дело со многими меньшими репозиториями, чем с одним большим. Например, если вы удаляете проект, вы можете просто архивировать репозиторий на носитель и удалить его с диска и освободить хранилище. Возможно, вам почему-то нужно сбросить/загрузить репозиторий, например, воспользоваться новой функцией Subversion. Это легче сделать и с меньшим воздействием, если это небольшой репозиторий. Даже если вы в конечном итоге захотите сделать это со всеми вашими репозиториями, это будет иметь меньшее влияние, чтобы делать их по одному, предполагая, что нет насущной необходимости делать их все сразу.
2. Глобальный номер редакции. Несмотря на то, что это не должно быть проблемой, некоторые люди воспринимают ее как одну и не любят видеть, что номер ревизии продвигается в репозитории, а для неактивных проектов - большие пробелы в истории изменений.
3. Контроль доступа. В то время как механизм authz Subversion позволяет вам ограничивать доступ по мере необходимости к частям репозитория, все же проще сделать это на уровне хранилища. Если у вас есть проект, доступ к которому возможен только отдельным пользователям, это проще сделать с одним репозиторием для этого проекта.
4. Административная гибкость. Если у вас несколько репозиториев, тогда проще реализовать разные скрипты hook, основанные на потребностях репозитория/проектов. Если вы хотите единообразные сценарии крючка, то один репозиторий может быть лучше, но если каждый проект хочет свой собственный совершать стиль электронной почты, то это легче иметь те проекты, в отдельных хранилищах

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

Answer 2

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

Answer 3

Я сохраняю один проект в репозитории и, как и предыдущий commenter, на этом subversion question, я помечаю совместно используемые проекты как внешние, так что они находятся только в контроле источника один раз.

Я только начинаю добавлять сервер сборки CI (CruiseControl.NET), поэтому мне нужно посмотреть, как все это работает, но если мои скрипты сборки правильные, это не должно быть проблемой.

Помимо внешнего вида, это действительно вопрос предпочтения (на мой взгляд).

Answer 4

Номер версии действительно должен быть только идентификатором для конкретной версии. Является ли это последовательным для проекта или нет, не имеет значения. Сказав это, я могу понять, что это меньше идеала.

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

Answer 5

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

С управлением версиями, особенно Subversion, вы можете легко проверить фрагменты репозитория в другой рабочей копии и затем перенести их обратно в свои соответствующие репозитории. Это позволяет вам четко различать и различать, предоставляя вам большую гибкость. Как только вы попадете в SVN немного больше (я предполагаю, что вы новичок.), Вы можете начать использовать крючки, и я могу увидеть, что может осложнить вам настройку.Если для вас важны разрешения, то один репозиторий может оказаться более сложным, чем необходимо.

Кроме того, если вы обеспокоены тем, что потребуется много времени, чтобы настроить каждый просмотр репозитория в переменной SVNParentPath для файла конфигурации Apache. (Опять же, я предполагаю, что вы используете Apache.)

Answer 6

Рекомендуется использовать отдельный репозиторий для каждого проекта. В моем каталоге conf.d Apache У меня есть subversion.conf, который содержит:

<Location /svn> 
    DAV svn 
    SVNParentPath /var/www/svn 

    AuthType Basic 
    AuthName "Subversion Repository" 
    AuthUserFile /var/www/svn/password 
    Require valid-user 
</Location> 

Тогда всякий раз, когда я начинаю новый проект, я просто запустить:

svnadmin create /var/www/svn/myproject 

Answer 7

Один репозиторий для каждого проекта.

Комментарий Стивена Муравски о CC.NET интересен. Мне было бы интересно узнать, как это работает, если вам нужно указать несколько репозиториев управления версиями.

Answer 8

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

Для меня большая причина использовать разные репозитории - обеспечить отдельный контроль доступа для пользователей и/или использовать разные скрипты hook.

Answer 9

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

Answer 10

На моем рабочем месте у нас есть два репозитория. Один с открытым доступом для чтения и один для всего остального. Я бы использовал только один для всего, но нам нужны разные права доступа для публичных/частных проектов.

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

Answer 11

@ Daniel Fone: Документы SVN рекомендуют один проект на репозиторий, так что это определенно способ, которым создатели планировали его использовать. Поскольку у вас может быть один сервер (apache или svnserve), поддерживающий несколько репозиториев, я никогда не сталкиваюсь с проблемой слишком больших издержек. С VisualSVN Server установка сервера apache и настройка нескольких хранилищ - это быстро.

Answer 12

Я не уверен, что документы SVN действительно рекомендуют один проект в репозитории. В основном они говорят о преимуществах и недостатках каждого пути. Я использую три разных репозитория, один для 7 или 8 проектов, которые все связаны, что делает его очень приятным, чтобы иметь возможность отправлять совместимые копии всех проектов, только строя из одной ревизии (или проверяя, что они совместимы, глядя на номера ревизий на каждом). Во втором репозитории имеется еще одна группа связанных проектов и документов, а третья - намного меньше. Это позволяет нам воспользоваться тем фактом, что связанные проекты могут управляться одним номером ревизии, но эти несвязанные проекты не влияют на их репозиторий.

Answer 13

У нас только один репозиторий со всем в нем, в значительной степени похожим на ваш пример.

Я не вижу ничего плохого в этом - единственное требование номер ревизии является то, что она

• Уникальный
• Atomic
• Больше, чем это было в прошлом оформленного

Не имеет значения, если он увеличивается на 1 или 50 с каждой фиксацией, насколько я могу судить.

@grom:

Тогда всякий раз, когда я начинаю новый проект, я просто запустить:

svnadmin create /var/www/svn/myproject

Я могу видеть это работает нормально, если вы получили только 1 или 2 devs, но что произойдет, если люди, которые создают новые проекты, не имеют доступа к оболочке на сервере SVN, чтобы иметь возможность создавать каталоги в/var/www?

Answer 14

Номера ревизий не имеют семантического использования. Единственное, что они находятся в последовательном порядке. Если вы сбрасываете проект и импортируете его в другой репозиторий, ваши версии могут получать новые номера ревизий. Итак, NEVER используйте номера ревизий, чтобы отметить ваши релизы или подобные материалы. Создайте теги для релизов (копии соответствующей ревизии).

Answer 15

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

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

Answer 16

Возможно, лучше не обязательно делать один репо на «проект», а, скорее, один репо на «решение» (использовать термины Visual Studio). Если у вас есть куча «проектов» в разных папках, но они связаны друг с другом, то помещайте их в одно и то же репо.

Answer 17

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

На самом деле, если ваш код здания Microsoft и вы используете номера версий svn как часть вашей строки версии, вы можете закончиться. Компилятор Microsoft выдает ошибку, если какая-либо часть строки версии больше 65535 .... В нашем случае у нас есть массивный репозиторий в редакции 68876, и мы просто попали в эту стену.