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

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

    / NinjaProg / филиалы
              / теги
              /хобот
    / StealthApp / филиалы
               / теги
               /хобот
    / SnailApp / филиалы
             / теги
             /хобот

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

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

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

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

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

19.08.2008 04:08:12
17 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

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

9
21.04.2011 13:41:42
Вторая ссылка на пост в блоге довольно проницательна, вы получили мой отклик. Первоначально я принял ответ на этот вопрос, но теперь я понимаю, что в вопросе о множественном репо и сингле не существует «наилучшей практики». Это зависит от ситуации (как говорится в статье в блоге)
Kit Roed 27.10.2008 14:40:11
Предупреждение: Когда номера ревизий кайфа в сценарии с несколькими проектами, есть одна функция SVN вы должны НЕ пытаться запустить: Revision graph. Это сканирует все ревизии до 1, независимо от того, связаны ли они с файлом, на котором вы его запускаете, или нет. После того, как вы подождали вечность, и инструмент отображается, вы получаете возможность отфильтровать, на каком номере ревизии вы хотите начать ...
awe 22.10.2010 08:36:15
Я попытался прочитать сообщение в блоге и получил проверку подлинности. Тем не менее, я смог найти копию на машине
pohl 20.04.2011 21:23:13

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

4
19.08.2008 04:12:56

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

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

Однако, кроме внешнего вида, это действительно вопрос предпочтений (по моему мнению).

1
23.05.2017 11:46:06

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

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

4
19.08.2008 04:15:23

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

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

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

6
19.08.2008 04:18:47
Нет, не принято разделять проекты на разные репозитории. У него есть преимущества помещать разные проекты в один и тот же репозиторий. Просто никогда не верь номерам ревизий. Они могут измениться, если вы сбросите / повторно импортируете.
Mnementh 3.12.2008 13:35:27

Рекомендуется использовать отдельный репозиторий для каждого проекта. В моем каталоге 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
3
19.08.2008 14:05:44

Один репозиторий на проект.

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

0
19.08.2008 12:28:22

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

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

2
19.08.2008 13:35:16

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

3
19.08.2008 14:15:52

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

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

3
19.08.2008 14:31:38

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

0
19.08.2008 19:28:45

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

0
25.08.2008 20:29:40

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

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

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

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

@grom:

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

svnadmin create /var/www/svn/myproject

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

4
25.08.2008 20:43:29

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

0
3.12.2008 13:33:12

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

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

0
4.12.2008 08:00:48
В настоящее время моя компания имеет 350 проектов из разных команд в одном хранилище Subversion. Глобальные номера редакций никогда не создавали проблем. Кому какое дело, если номера ревизий подскочат более чем на 1 для конкретного проекта? Ваш проект будет иметь изменения только на небольшом подмножестве ревизий. Легко понять. У меня есть проекты, где количество ревизий подскочило на несколько тысяч между коммитами. Это не вызывает у меня горя.
Michael 14.03.2012 15:28:56

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

2
29.07.2012 05:55:04

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

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

1
22.04.2013 13:21:52