Когда мне проверить TRUNK против ПОЛНОГО ПРОЕКТА в репозитории SVN? - PullRequest
Новая
       43

Когда мне проверить TRUNK против ПОЛНОГО ПРОЕКТА в репозитории SVN?

13 голосов
/ 30 июня 2010

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

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

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

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

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

Best.

Ответы [ 4 ]

10 голосов
/ 30 июня 2010

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

  1. филиалы
  2. метка
  3. багажник

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

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

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

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

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

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

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

9 голосов
/ 30 июня 2010

Есть еще несколько моментов, на которые следует обратить внимание:

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

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

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

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

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

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

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

3 голосов
/ 30 июня 2010

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

3 голосов
/ 30 июня 2010

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

/trunk
/tags
/branches

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

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

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

...