Когда я проверяю СОЕДИНИТЕЛЬНУЮ ЛИНИЮ по сравнению с ПОЛНЫМ ПРОЕКТОМ в SVN repo?

Question

Когда я проверяю СОЕДИНИТЕЛЬНУЮ ЛИНИЮ по сравнению с ПОЛНЫМ ПРОЕКТОМ в SVN repo?

Стал (надо надеяться, маленьким) вопрос относительно SVN и проверяющий repos. В основном я посмотрел относительно конфликтующие учебные руководства и предложения, что проверить и когда. Некоторые скажут:

svn co http://my.repos.com/project my_project

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

svn co http://my.repos.com/project/trunk my_project

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

С наилучшими пожеланиями.

13

svn version-control project trunk

задан humble_coder 29 June 2010 в 22:36

4 ответа

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

ветки
теги
ствол

Транк - это самая последняя ветвь кода.

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

Теги подобны точкам сохранения ствола.

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

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

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

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

10

ответ дан 1 December 2019 в 21:36

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

3

ответ дан 1 December 2019 в 21:36

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

/trunk
/tags
/branches

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

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

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

3

ответ дан 1 December 2019 в 21:36

Другие вопросы по тегам:

svn version-control project trunk

Похожие вопросы:

score 9 · Accepted Answer

Есть еще пара замечаний по этому поводу.

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

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

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

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

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

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

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