Номер редакции Subversion в нескольких проектах
https://stackoverflow.com/questions/15674
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
При использовании Subversion (svn) для управления версиями с несколькими проектами я заметил, что номер редакции увеличивается во всех каталогах моих проектов.Чтобы проиллюстрировать мой макет svn (используя вымышленные названия проектов):
/NinjaProg/branches
/tags
/trunk
/StealthApp/branches
/tags
/trunk
/SnailApp/branches
/tags
/trunk
Когда я выполняю фиксацию в магистрали программы Ninja, допустим, я получаю, что она была обновлена до версии 7.Допустим, на следующий день я внесу небольшое изменение в приложение Stealth, и оно вернется как версия 8.
Вопрос заключается вот в чем: Является ли общепринятой практикой при обслуживании нескольких проектов с помощью одного сервера Subversion увеличение номера редакции несвязанных проектов во всех проектах? Или я делаю это неправильно и должен создавать отдельные репозитории для каждого проекта?Или это что-то совсем другое?
Редактировать: Я задержался с ответом, потому что стало ясно, что для обоих подходов есть причины, и хотя этот вопрос был первым, я хотел бы указать на некоторые другие вопросы, которые в конечном итоге задают тот же вопрос:
Должен ли я хранить все проекты в одном репозитории или нескольких?
Решение
Я удивлен, что никто не упомянул, что это обсуждается в системе управления версиями с Subversion, которая доступна бесплатно онлайн, здесь.
Я читал об этом некоторое время назад, и это действительно кажется вопросом личного выбора, есть хороший пост в блоге на эту тему здесь.Редактировать: Поскольку блог, похоже, не работает, (архивированная версия здесь), вот кое-что из того, что Марк Фиппард сказал по этому поводу.
Таковы некоторые из преимуществ подхода с единым репозиторием.
- Упрощенное администрирование.Один набор крючков для развертывания.Один репозиторий для резервного копирования.и т.д.
- Гибкость ветвей / тегов.Поскольку весь код находится в одном репозитории, это упрощает создание ветки или тега, включающего несколько проектов.
- Легко перемещайте код.Возможно, вы хотите взять фрагмент кода из одного проекта и использовать его в другом или превратить его в библиотеку для нескольких проектов.Легко переместить код в один и тот же репозиторий и сохранить историю кода в процессе.
Вот некоторые недостатки подхода с одним репозиторием и преимущества подхода с несколькими репозиториями.
- Размер.Возможно, было бы проще иметь дело со многими небольшими репозиториями, чем с одним большим.Например, если вы завершаете проект, вы можете просто заархивировать репозиторий на носитель, удалить его с диска и освободить хранилище.Возможно, вам по какой-то причине нужно создать дамп / загрузить репозиторий, например, чтобы воспользоваться преимуществами новой функции Subversion.Это проще сделать и с меньшим эффектом, если это хранилище меньшего размера.Даже если вы в конечном итоге захотите сделать это со всеми своими репозиториями, выполнение их по одному окажет меньшее влияние, предполагая, что нет острой необходимости делать их все сразу.
- Глобальный номер редакции.Несмотря на то, что это не должно быть проблемой, некоторые люди воспринимают это как проблему, и им не нравится, когда номер редакции увеличивается в репозитории, а неактивные проекты имеют большие пробелы в истории ревизий.
- Контроль доступа.Хотя механизм аутентификации Subversion позволяет вам при необходимости ограничивать доступ к частям репозитория, сделать это на уровне репозитория все же проще.Если у вас есть проект, доступ к которому имеют только избранные, это проще сделать с помощью единого репозитория для этого проекта.
- Административная гибкость.Если у вас несколько репозиториев, то проще реализовать различные скрипты перехвата в зависимости от потребностей репозитория / проектов.Если вам нужны унифицированные скрипты перехвата, то лучше использовать единый репозиторий, но если каждому проекту нужен свой собственный стиль электронной почты для фиксации, то проще разместить эти проекты в отдельных репозиториях
Если вы действительно задумаетесь, то количество редакций в репозитории с несколькими проектами вырастет, но у вас это не закончится.Имейте в виду, что вы можете просмотреть историю в подкаталоге и быстро просмотреть все номера редакций, относящиеся к проекту.
Другие советы
Я думаю, настоятельно рекомендуется создавать отдельные репозитории для каждого проекта.Хотя бы для того, чтобы избежать сценария, о котором вы говорите.
С помощью системы управления версиями, особенно Subversion, вы можете легко извлечь фрагменты репозитория в другую рабочую копию, а затем зафиксировать их обратно в соответствующие репозитории.Это позволяет вам четко разделять их, предоставляя при этом большую гибкость.Как только вы немного освоитесь с SVN (я предполагаю, что вы новичок.), вы можете начать использовать хуки, и я, возможно, увижу, где это может усложнить вашу настройку.Если для вас важны разрешения, создание одного репозитория может оказаться сложнее, чем необходимо.
Кроме того, если вы обеспокоены тем, что настройка каждого репозитория займет много времени, загляните в переменную SVNParentPath для файла конфигурации Apache.(Опять же, я предполагаю, что вы используете Apache.)
Это связано с тем, как работает subversion.Каждая редакция на самом деле является моментальным снимком репозитория, идентифицируемого этим номером редакции.Если все ваши проекты совместно используют репозиторий, то это неизбежно.Однако, как правило, по моему опыту, вы настраиваете отдельные репозитории для совершенно не связанных проектов.Итак, короткий ответ - нет, вы не делаете ничего плохого, это распространенный вопрос, связанный с subversion, но это имеет смысл, когда вы думаете о том, как он хранит информацию о репозитории.
Номер редакции на самом деле должен быть идентификатором только для определенной версии.Является ли это последовательным для проекта или нет, не должно иметь значения.Тем не менее, я могу понять, что это далеко не идеально.
Большинство проектов, с которыми я сталкивался, были настроены в одном репозитории, и идентификаторы версий ведут себя именно таким образом.Я не знаю ни одного варианта конфигурации SVN, который мог бы изменить это поведение, и, ИМХО, поддержание нескольких репозиториев кажется ненужными накладными расходами.
У нас просто есть один репозиторий со всем, что в нем есть, почти в точности как в вашем примере.
Я не вижу в этом ничего плохого - единственное требование к номеру редакции заключается в том, что он
- Уникальный
- Атомный
- Больше, чем было при последней проверке
Насколько мне известно, не имеет значения, увеличивается ли он на 1 или на 50 с каждым коммитом.
@grom:
Затем всякий раз, когда я начинаю новый проект, я просто запускаю:
svnadmin create /var/www/svn/myproject
Я вижу, что это работает нормально, если у вас есть только 1 или 2 разработчика, но что произойдет, если люди, создающие новые проекты, не имеют доступа к оболочке на сервере SVN, чтобы иметь возможность создавать каталоги в /var / www?
Рекомендуется использовать отдельный репозиторий для каждого проекта.В моем каталоге 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
Хм, там, где я работаю, у нас все наши проекты хранятся в одном репозитории.Я действительно не вижу пользы в их разделении, разве это не создает много дополнительной работы - создание новых репозиториев, предоставление доступа людям и т.д.?Я предполагаю, что отдельные репозитории имеют смысл, если проекты совершенно не связаны, и у вас есть, скажем, внешние заказчики, которым необходимо иметь доступ к репозиторию.
На моем рабочем месте у нас есть два хранилища.Один с общедоступным доступом для чтения, и один для всего остального.Я бы использовал только один для всего, но нам нужны разные права доступа для публичных / частных проектов.
Тем не менее, я лично не вижу проблемы с увеличением номеров версий при каждом обновлении.Номера версий могут пропускать простые и четные числа и по-прежнему делать то, что они должны делать.Упростите переход к конкретной редакции.
Если вас беспокоит изменение номеров редакций в зависимости от других проектов, то поместите проекты в отдельные репозитории.Это единственный способ сделать номера ревизий независимыми.
На мой взгляд, основной причиной использования разных репозиториев является предоставление отдельного контроля доступа для пользователей и / или использование разных скриптов подключения.
Возможно, лучше не обязательно делать одно репо для каждого "проекта", а скорее одно репо для каждого "решения" (если использовать термины Visual Studio).Если у вас есть куча "проектов" в разных папках, но они связаны друг с другом, то поместите их в одно репозиторий.
Я храню по одному проекту в каждом репозитории, и, как и предыдущий commenter на этом вопрос о подрывной деятельности, Я помечаю общие проекты как внешние, так что они находятся в системе управления версиями только один раз.
Я только начинаю добавлять сервер сборки CI (CruiseControl.NET), поэтому мне нужно будет посмотреть, как все это работает, но если мои сценарии сборки верны, это не должно быть проблемой.
Однако, помимо внешнего вида, это действительно вопрос предпочтений (на мой взгляд).
Если вы действительно задумаетесь, то номера ревизий в репозитории с несколькими проектами будут высокими, но вы не собираетесь исчерпывать их .Имейте в виду, что вы можете просмотреть историю в подкаталоге и быстро просмотреть все номера редакций, относящиеся к проекту.
На самом деле, если вы создаете код Microsoft и используете номера версий svn как часть вашей строки версии, то у вас может закончиться.Компилятор Microsoft выдаст ошибку, если какая-либо часть строки версии больше 65535....В нашем случае у нас есть огромный репозиторий с версией 68876, и мы просто натыкаемся на эту стену.
Один репозиторий на проект.
Комментарий Стивена Муравски по поводу CC.NET интересный.Мне было бы интересно услышать, как это работает, если вам нужно указать несколько репозиториев системы управления версиями.
@Дэниел Фонэ:Документы SVN рекомендуют по одному проекту для каждого репозитория, так что создатели определенно предполагали, что все пойдет именно так.Поскольку у вас может быть один сервер (apache или svnserve), поддерживающий несколько репозиториев, я никогда не сталкивался с проблемой слишком больших накладных расходов.С Сервер VisualSVN, установить сервер apache и настроить несколько репозиториев совсем несложно.
Я не уверен, что документы SVN действительно рекомендуют один проект для каждого репозитория.В основном они говорят о плюсах и минусах каждого пути.Так получилось, что я использую три разных репозитория, по одному для 7 или 8 проектов, которые все связаны, что делает очень приятным возможность отправлять совместимые копии всех проектов, просто создавая их из одной ревизии (или проверяя их совместимость, просматривая номера ревизий в каждой).Во втором хранилище есть еще одна группа связанных проектов и документов, в то время как третье намного меньше.Это позволяет нам воспользоваться тем фактом, что связанными проектами можно управлять с помощью одного номера редакции, но что несвязанные проекты не влияют на их репозиторий.
Номера версий не имеют семантического применения.Единственное, что важно, это то, что они расположены в последовательном порядке.Если вы создадите дамп своего проекта и импортируете его в другой репозиторий, ваши версии могут получить новые номера версий.Итак НИКОГДА используйте номера редакций, чтобы отмечать свои выпуски или подобные материалы.Сделайте теги для выпусков (копии соответствующей редакции).
У меня была такая же проблема в моей предыдущей компании, у них было около 50 проектов, запущенных в одном репозитории, и работать над одними и теми же проектами было кошмаром, потому что при выполнении обновлений svn другие проклинали ....лол...
Я усвоил одну вещь, которая всегда срабатывает лучше всего: один проект, одно репо .... вы никогда не пожалеете об этом.
