вопросы структуры подрывной деятельности - PullRequest
3 голосов
/ 06 февраля 2009

Только что перешел в Subversion ... из Visual Studio. Я уже люблю это! Может кто-нибудь кратко объяснить

  1. Хранилище
  2. Филиалы
  3. Метки
  4. Магистральные

Нужно ли создавать новый репозиторий для каждого проекта? Или новый багажник?

Спасибо

Ответы [ 5 ]

13 голосов
/ 06 февраля 2009

Помните, что Subversion - это просто модная файловая система, которая поддерживает управление версиями. Думайте о хранилище как о «корне диска», таком как «C: /».

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

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

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

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

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

Вам не нужен отдельный репозиторий, но вы можете, если хотите. Я рекомендую прочитать книгу по адресу http://svnbook.red -bean.com / . Возьмите PDF-версию или что-то еще. Это не займет много времени, и это объясняет некоторые вещи довольно хорошо. Я прочитал это и обнаружил, что рад, что сделал.

7 голосов
/ 06 февраля 2009

Согласен, прочитайте svnbook . Это отличный ресурс.

Нужно ли создавать новый репозиторий для каждого проекта? Или новый багажник?

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

  1. Репозиторий
  2. Филиалы
  3. Метки
  4. Магистральные

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

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

В зависимости от того, сколько проектов вы решили иметь в своем хранилище, вы можете организовать их по-разному.

Вы можете иметь подкаталоги с проектами под ним:

\repo
  \branches
    \...
  \tags
    \...
  \trunk
    \..

или у вас могут быть проекты, содержащие подкаталоги:

\repo
  \Project1
    \branches
    \tags
    \trunk
  \Project2
    \branches
    \tags
    \trunk

Есть компромиссы, которые описаны в svnbook. Первый метод обычно используется, если у вас есть только один проект на репозиторий, а второй - если в вашем репозитории более одного проекта.

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

3 голосов
/ 06 февраля 2009

Важная вещь, которую следует помнить с SVN, по сравнению с другими системами контроля версий, такими как CVS или Git, заключается в том, что SVN на самом деле не имеет концепции, разветвления или тегирования. Что касается SVN, то это всего лишь куча папок и файлов. Так что, хотя вы увидите, что многие люди используют установку веток / тегов / ствола, это не обязательно, и вы можете отклониться от этого, если захотите.

Вообще говоря, «ствол» - это то место, где вы продолжаете активно развиваться. Так вот, где вы делаете все свои коммиты. Независимо от того, заказываете ли вы ствол или используете вместо него теги / ветви, полностью зависит от вас.

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

\repo
  \trunk
  \branches
    \version_two

В этом случае вы можете разрабатывать как trunk, так и version_two по отдельности, и, предполагая, что ваш живой сайт является извлечением ствола, вам не нужно беспокоиться о «случайном» разрыве вашего живого сайта с другими вашими изменениями. И когда эти изменения сделаны и готовы, вы можете просто слить их обратно в транк, когда захотите.

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

/repo
  /trunk
  /branch
    /version_one
    /version_two
  /tags
    /1.0.0
    /1.0.1
    /1.1.0

В этом случае общая идея заключается в том, что, когда вы готовы выполнить развертывание, вы делаете

svn copy

Чтобы скопировать транк в тег (в этом случае следующий может быть 1.1.1, 1.2.0, 2.0.0 и т. Д.). Как вы называете свои теги, это полностью зависит от вас, и, опять же, зависит от вашего проекта и требований. С этим маршрутом вместо обычного 'svn up' вы должны сделать svn switch. Таким образом, вы должны развернуть с

svn switch https://svn.yourrepo.com/repo/tags/1.1.0

Коммутатор автоматически обновляет, добавляет и удаляет соответствующие файлы.

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

2 голосов
/ 06 февраля 2009

Читая ваши теги, я вижу, вы начали использовать VisualSVN вместо старой системы VSS. (Ваш вопрос говорит о том, что вы перестали использовать Visual Studio ..., что делает VisualSVN странным выбором).

Одно из основных отличий между SourceSafe и VSS заключается в том, что вы можете выбирать разные инструменты для доступа к одному и тому же репозиторию (и вы можете переключаться каждый раз, когда захотите, поскольку все они используют одну и ту же рабочую копию).

например:.

  • TortoiseSVN для интеграции с Explorer.
  • Обычный клиент Subversion для скриптов.
  • VisualSVN в качестве внешнего интерфейса Visual Studio для TortoiseSVN
  • AnkhSVN как реальный пакет SCC (VAPI) в Visual Studio.
...