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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@grom:

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

svnadmin create /var/www/svn/myproject

Я вижу, что это работает нормально, если у вас есть только 1 или 2 разработчика, но что произойдет, если люди, которые создают новые проекты, не имеют доступа shell на сервере 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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