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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

• Уникальный
• Atomic
• Больше, чем при последней проверке

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

@grom:

Затем, когда я запускаю новый проект, я просто запускаю:

svnadmin create /var/www/svn/myproject

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

Ответ 6

Рекомендуется использовать отдельный репозиторий для каждого проекта. В моем каталоге Apache conf.d у меня есть 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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

Номера ревизий не имеют семантического использования. Единственное, что они находятся в последовательном порядке. Если вы сбрасываете проект и импортируете его в другой репозиторий, ваши версии могут получать новые номера ревизий. Поэтому НИКОГДА используйте номера версий, чтобы отметить ваши релизы или похожие материалы. Создайте теги для релизов (копии соответствующей версии).

Ответ 17

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

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