2010-06-29 6 views
11

Получил (надеюсь, небольшой) вопрос относительно SVN и проверки репозиториев. В основном я вижу противоречивые учебники и предложения относительно того, что проверить и когда. Некоторые скажут:Когда я просматриваю TRUNK vs FULL PROJECT в репо SVN?

СВН совместно http://my.repos.com/project my_project

... в то время как другие говорят:

СВН совместно http://my.repos.com/project/trunk my_project

Когда я хочу, чтобы захватить ствол прямо против всего проекта? Раньше у меня никогда не было проблем с этим, но я не уверен, есть ли сценарии, где один предпочтительнее другого.

Лучший.

ответ

7

Для этого есть еще несколько моментов.

  1. tags дерева (и это, как правило, дерево) содержит гипотетический неизменные снимки вашего кода в определенный момент времени; это не то, что вы хотите изменить, так как большинство развертываний будут основаны на бирках
  2. Большинство клиентов Subversion жалуются, если вы попытаетесь совершить изменения в tags дерева, вместо того, чтобы просто скопировать в него
  3. Для большинства целей, trunk - частный случай каталогов под branches; единственное существенное различие заключается в том, что он должен содержать основной путь развития.

Обычно нет причин для проверки всего проекта, как указывали другие, поскольку большую часть времени вы работаете только ствол и одна или две ветки, и весь проект может съесть значительное количество дискового пространства. Главное развитие «отрасли» - это, скорее всего, единственное, что вам нужно.

Вот пример реального мира. Наша команда делает все изменения кода в отношении багажника. Когда нам нужна альфа-версия (pre-complete), мы просто отмечаем багажник. Как только мы нажмем «code complete» для данной версии, мы создаем ветвь «замораживание кода», где мы делаем все наши изменения в версии. Бета-версии и RC-релизы помечены из этой ветви. Если нам нужно исправить выпуск GA, патч будет сделан против ветки и объединен с багажником. Таким образом, нам не нужно беспокоиться о том, что новый код протекает в тестируемом и одобренном GA, если нам нужно исправить что-то конкретное. Это также позволяет нам начать работу над следующей версией программного обеспечения, как только код будет заморожен.

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

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

Кроме того, просто пункт управления хранилищем, упомянутый @humble_coder - большинство инструментов Subversion довольно просты в использовании, когда дело доходит до управления веткой/тегом. Например, TortoiseSVN имеет браузер репозитория, который позволяет вам легко копировать вещи (создание ветвей и тегов), и даже инструмент командной строки svn можно использовать для выполнения той же самой операции, что и атомная операция (у нас есть сценарий который создает либо альфа-теги, ветвь замораживания кода, либо теги релиза после замораживания).

Надеюсь, это поможет!

3

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

/trunk 
/tags 
/branches 

Внутри обоих tags и branches, вы можете иметь несколько копий проекта (опять-таки в зависимости от как вы используете репозиторий).

Если вы разместили этот репозиторий таким образом, и вы проверите /, вы получите несколько копий кода (тегов и веток), что вы, возможно, не должны касаться (например, тегов).

Если вы заказываете /trunk, вместо этого вы проверите только версию, в которой вы сейчас работаете, и это то, что вы обычно хотите.

+0

А, так что, если бы я был руководителем проекта, я мог бы проверить все, чтобы обрабатывать ветки и т. Д.? –

+0

Вы можете, но вы также можете проверить только ту часть или отдельную ветвь и использовать команду 'svn switch', чтобы переключить рабочую копию из одной ветви в тубу. Вы можете обнаружить, что проверка всего проекта съест много дискового пространства, более того, если вы часто используете теги и ветви. – pgb

9

обычно хранилище подрывной имеет 3 основных каталогов:

  1. ветви
  2. теги
  3. ствол

Ствол является для самой свежей ветви кода.

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

Метки как точки сохранения ствола.

Если вы делаете чек в корне проекта, вы получите все ветки, все теги и багажник. Это может привести к огромному объему данных.

Например, если каждый выпуск кода помечен, вы получите исходный код из всех ваших прошлых выпусков!

Я надеюсь, что это поможет вам

Джерома Вагнер

+1

Согласовано. И * большинство * времени, когда большинству разработчиков не нужно ничего больше, чем/trunk и ветка или две, на которых они работают/разрешают ошибки. Остальные - особенно теги - будут использоваться редко. В основном я перехожу к своим тегам, пытаясь воспроизвести отчет об ошибке. Это надежный способ узнать, что у вас такая же версия, как и у пользователя. – CaseySoftware

3

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

 Смежные вопросы

  • Нет связанных вопросов^_^