Когда я просматриваю TRUNK vs FULL PROJECT в SVN-репо?

Ответ 1

Есть еще несколько замечаний об этом.

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

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

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

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

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

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

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

Ответ 2

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

• ветки
• теги
• багажник

Магистраль предназначена для самой последней ветки кода.

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

Теги похожи на точки сохранения соединительной линии.

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

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

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

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

Ответ 3

Это зависит от того, как вы выкладываете свой репозиторий, но обычно у вас будет такая структура:

/trunk
/tags
/branches

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

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

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

Ответ 4

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