Как правильно создать тег SVN из транка?

282

Я создаю свой первый проект в Subversion . Пока у меня есть

 branches
 tags
 trunk

Я думаю, что мне сразу нужно сделать ветки единичными и начать все сначала. Обновление веток это норма.

Я выполнял работу в транке и перемещал содержимое в теги следующим образом.

mkdir tags/1.0
cp -rf trunk/* tags/1.0
svn add tags/1.0
svn commit -m " create a first tagged version"

Моя интуиция говорит мне, что это совершенно неправильно, и я должен поддерживать некоторые отношения между файлами, использующими svn copy. Файлы, которые я создаю таким образом, не будут иметь никакого отношения друг к другу, и я уверен, что пропущу функции Subversion. Я прав?

Должен ли я использовать копию SVN для отдельных файлов?

mkdir tags/1.0
svn add tags/1.0
svn copy trunk/file1 tags/1.0
svn copy trunk/file2 tags/1.0
svn copy trunk/file3 tags/1.0
svn commit -m " create a first tagged version"

Должен ли я использовать копию SVN на весь каталог?

svn copy cp -rf trunk tags/1.0
svn commit -m " create a first tagged version"
ojblass
источник
10
К сожалению, я не делаю весь выбор в этом случае ... мерзавец довольно чертовски волшебен
ojblass

Ответы:

186

Вы правы в том, что не правильно добавлять файлы в папку тегов.

Вы правильно догадались, что copyэто операция для использования; это позволяет Subversion отслеживать историю этих файлов, а также (я полагаю) хранить их гораздо эффективнее.

По моему опыту, лучше всего делать копии («снимки») целых проектов, то есть всех файлов из корневой папки извлечения. Таким образом, снимок может стоять сам по себе, как истинное представление всего состояния проекта в определенный момент времени.

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

размотать
источник
15
Версия 1.1 книги ужасно устарела. Вот лучшая ссылка: svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
Куинн Тейлор,
1
скопированные файлы не занимают лишнего места
Карлос
424

Использование:

svn copy http://svn.example.com/project/trunk \
      http://svn.example.com/project/tags/1.0 -m "Release 1.0"

стенографии:

cd /path/to/project
svn copy ^/trunk ^/tags/1.0 -m "Release 1.0"
Виктор Гюго
источник
36
Я отметил это как ответ. Всего одна дополнительная заметка. Вы можете получить предыдущую ревизию ствола и также пометить ее. команда: svn copy -r 123 " svn.example.com/project/trunk " " svn.example.com/project/tags/1.0 " -m "Пометка, но с использованием более старой версии (123)."
granadaCoder
7
Я получаю svn: Локальные операции без фиксации не принимают сообщения журнала или свойства ревизии , поэтому я просто удаляю опцию -m.
Джонни
4
Просто к сведению, убедитесь, что ваш URL соответствует вашему хранилищу, включая http или https.
Норман Х
2
Почему \ в конце первой строки?
Фракталист
1
@Jonny Я не могу запустить вышеуказанную команду без опции "-m". Я использую терминал на Mac.
Абдуррахман Мубин Али
14

Как отметил @victor hugo, «правильный» способ - использовать svn copy. Есть одно предостережение, хотя. Созданный таким образом «тег» не будет истинным тегом, он будет точной копией указанной ревизии, но сам будет другой ревизией. Таким образом, если ваша система сборки каким-то образом использует svn-ревизию (например, включает число, полученное с помощью 'svn info' в версию продукта, который вы собираете), то вы не сможете собрать точно такой же продукт из тега ( результат будет иметь ревизию тега вместо ревизии исходного кода).

Похоже, что в SVN нет способа создать действительно правильный метатег.

Александр Амелькин
источник
4
Можно использовать «Last Changed Rev»: echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt`
18446744073709551615
Таким образом, две ветви с (конечно) разными номерами ревизий все еще производят одну и ту же версию программного обеспечения.
18446744073709551615
1
Да, вы правы насчет Last Changed Rev, но это не меняет того факта, что в Subversion нет реальных тегов.
Александр Амелькин
@ 18446744073709551615: Вы можете избежать использования awkи получать эту информацию прямо из SVN, используя --show-itemопцию:svn info --show-item last-changed-revision
Luchostein
12

Просто используйте это:

svn  copy  http://svn.example.com/project/trunk  
           http://svn.example.com/project/branches/release-1
           -m  "branch for release 1.0"

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

См лучшее резюме использования SVN в моем блоге: SVN Основы и SVN Основы 2

AgilePro
источник
Можете ли вы уточнить, как это должно выглядеть, если я проверяю только из багажника, и я внутри с моим сценарием.
Ахолбрайх
Если вы извлекли папку ствола, то вам необходимо использовать http-адрес хранилища. Я обновил ответ, чтобы представить это, так как проверка папки ствола - рекомендуемый образец.
AgilePro
Чем этот ответ отличается от принятого?
Даниэль У.
11

Могли бы использовать черепаху:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html

Громер
источник
1
Я собираюсь построить систему большего размера, поэтому мне нужно сосредоточиться на основных функциях.
ojblass
2
Спасибо! Командная строка может быть правильной, но это было более полезно.
Ray301
7

@victor Гюго и @unwind верны, и решение Виктора является самым простым. Однако остерегайтесь внешнего в вашем проекте SVN. Если вы ссылаетесь на внешние библиотеки, ссылка на внешнюю ревизию (тег, или HEAD, или номер) останется неизменной, если вы пометите каталоги, имеющие внешние ссылки.

Можно создать сценарий для обработки этого аспекта тегирования, для обсуждения этой темы см. Эту статью SO: Пометка проверки SVN с помощью внешних

MOK9
источник
5

Другой вариант пометить хранилище Subversion - добавить тег в свойство svn: log следующим образом:

   echo "TAG: your_tag_text" > newlog
   svn propget $REPO --revprop -r $tagged_revision >> newlog
   svn propset $REPO --revprop -r $tagged_revision -F newlog
   rm newlog

Недавно я начал думать, что это самый «правильный» способ пометки. Таким образом, вы не создаете дополнительные ревизии (как вы делаете с «svn cp») и все еще можете легко извлечь все теги, используя grep в выводе «svn log»:

   svn log | awk '/----/ {
                      expect_rev=1;
                      expect_tag=0;
                  }
                  /^r[[:digit:]]+/ {
                      if(expect_rev) {
                          rev=$1;
                          expect_tag=1;
                          expect_rev=0;
                      }
                  }
                  /^TAG:/ {
                      if(expect_tag) {
                          print "Revision "rev", Tag: "$2;
                      }
                      expect_tag=0;
                  }'

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

Александр Амелькин
источник
0
svn copy http://URL/svn/trukSource http://URL/svn/tagDestination -m "Test tag code" 
  $error[0].Exception | Select-object Data

Все, что вам нужно сделать, изменить URL-путь. Эта команда создаст новый каталог "tagDestination". Во второй строке будет дана полная информация об ошибке, если она возникнет. Создайте переменную svn env, если она не создана. Можно проверить (Cmd: - установить, Powershell: - Get-ChildItem Env :) Путь по умолчанию: «C: \ Program Files \ TortoiseSVN \ bin \ TortoiseProc.exe»

Ашу
источник
-4

Попробуй это. Меня устраивает:

mkdir <repos>/tags/Release1.0
svn commit <repos>/tags/Release1.0 
svn copy <repos>/trunk/* <repos>/tag/Release1.0
svn commit <repos/tags/Release1.0 -m "Tagging Release1.0"
iboubuntu
источник
1
Это определенно неправильный путь. Тег (Release1.0) должен быть копией исходного каталога (транка), а не произвольно созданного каталога. Если вы делаете это так, как вы это делали, вы теряете историю самого исходного каталога и сохраняете историю только потомков (файлов и каталогов).
Александр Амелькин