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

Question

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

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

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

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

РЕДАКТИРОВАТЬ: Я отложил пометку ответа, потому что стало ясно, что есть причины для обоих подходов, и хотя этот вопрос возник первым, я хотел бы указать на некоторые другие вопросы, которые в конечном счете, задавая тот же вопрос:

Должен ли я хранить все проекты в одном хранилище или в нескольких хранилищах?

Один репозиторий SVN или много?

Answer 1

Я удивлен, что никто не упомянул, что это обсуждается в Контроле версий с Subversion, который доступен бесплатно онлайн, здесь .

Я перечитал вопрос некоторое время назад, и это действительно кажется вопросом личного выбора, здесь есть хорошая запись в блоге на эту тему здесь . РЕДАКТИРОВАТЬ: Поскольку блог, кажется, не работает, ( архивная версия здесь ), вот кое-что из того, что Марк Фиппард сказал по этому вопросу.

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

• Уникальная
• Атомный
• Больше, чем было при последней регистрации

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

@ Grom:

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

svnadmin create /var/www/svn/myproject

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

Answer 4

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

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

Answer 5

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

Answer 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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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