Subversion та же ревизия для пометки или фиксации нескольких проектов - PullRequest
2 голосов
/ 17 марта 2010

Как сделать теги для нескольких проектов в одной ревизии?
Например, если ему нужно пометить тем же именем:

svn copy svn://localhost/BigProject/Project1/trunk svn://localhost/BigProject/Project1/tags/1.0.0 --message "1.0.0"
svn copy svn://localhost/BigProject/Project2/trunk svn://localhost/BigProject/Project2/tags/1.0.0 --message "1.0.0"
...
svn copy svn://localhost/BigProject/ProjectX/trunk svn://localhost/BigProject/ProjectX/tags/1.0.0 --message "1.0.0"

Но этот фрагмент делает X ревизий. Итак, как сделать только одну ревизию или как интегрировать все в одну?
Другой вопрос, как зафиксировать подобные изменения в одной ревизии?
ТИА

Издание для лучшего понимания:

  • Номер редакции тега используется в версиях проектов. Таким образом, в приведенном выше случае все проекты имеют разные версии с одинаковым тегом.
  • Другая версия требуется только в том случае, если конкретная модификация была сделана только для одного проекта. Вынужден добавить четвертый октет к номеру версии.
  • Стремление уменьшить количество повторяющихся X раз сообщений журнала для всего BigProject.

Ответы [ 6 ]

1 голос
/ 18 июля 2012

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

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

Следующие команды должны достичь того, что вы пытаетесь сделать:

svn co svn://localhost/BigProject --depth=immediates shallow-checkout
cd shallow-checkout
ls   # you will have one empty dir for each project: Project1, Project2, ...
svn update --set-depth=immediates *
  # Each project dir will now have a "trunk" and a "tags" dir, with no content.
  # You do not need to check out all the 'trunk' content, the 'copy' command will still work
  # now make the copies in the WC:
svn cp Project1/trunk Project1/tags/1.0.0
svn cp Project2/trunk Project2/tags/1.0.0
svn cp Project3/trunk Project3/tags/1.0.0
svn cp Project4/trunk Project4/tags/1.0.0
  # make all the tags in one atomic commit:
svn ci -m 'create 1.0.0 tag for projects 1-4'

Хотя, как указывалось в других ответах, лучшим решением является использование более обычной компоновки SVN.

1 голос
/ 28 января 2011

Вы получите решение, очень похожее на пост кубанакана, используя Subversive в Eclipse.

Имея такую ​​настройку проекта:

subproject1
  trunk
  tags
  branches
subproject2
  trunk
  tags
  branches
masterproject
  trunk
    svn:externals to subproject1/trunk
                 and subproject2/trunk
    masterthings
  tags
  branches

Имея рабочую копию masterproject, Subversive создаст тэг, используя текущую версию externals, они называют его freeze svn: externals Пример:

masterproject
  trunk
    svn:externals to subproject1/trunk
                 and subproject2/trunk
    masterthings
  tags
    v1.0
      svn:externals to subproject1/trunk at rev. 123
                   and subproject2/trunk at rev. 234
      masterthings at rev. 12345
  branches

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

Для внешних объектов, указывающих на репозитории без прав записи, это также хорошее решение.

0 голосов
/ 19 марта 2010

Основываясь на сообщении Джошуа МакКиннон , я нашел решение для моего второго вопроса (о принятии в одну ревизию):

  1. Создать папку, например trunk.
  2. Оформить эту папку из svn://localhost/BigProject/trunk.
  3. Добавить свойство svn, svn:externals, с содержанием:

    svn://localhost/BigProject/Project1/trunk Project1
    svn://localhost/BigProject/Project2/trunk Project2
    ...
    svn://localhost/BigProject/ProjectX/trunk ProjectX
    
  4. Обновление trunk, чтобы все стволы ваших проектов были в одной рабочей копии.

  5. Теперь пакет с аналогичными модификациями может быть зафиксирован в одной и той же редакции для всех проектов.

Редакция для решения первого вопроса (пометка в пределах одной ревизии).

Я исследовал множество подходов, и простейшим решением является реструктуризация репо:

BigProject
    tags
    trunk
        Project1
            branches
            trunk
        Project2
            branches
            trunk
        ProjectX
            branches
            trunk

А теперь можно было бы использовать просто svn copy строку:

svn copy svn://localhost/BigProject/trunk svn://localhost/BigProject/tags/1.0.0
0 голосов
/ 17 марта 2010

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

Вот что я предлагаю:

Сначала сделайте то, что вы уже показали выше (набор команд SVN Copy), чтобы создать теги 1.0.0 для всех ваших проектов. Затем создайте область по вашему выбору (BigProject / теги могут не иметь смысла, учитывая макет, который вы уже получили - просто выберите местоположение.)

Я пойду с svn: // localhost / Releases / BigProject / для своих собственных целей, так как вы можете захотеть, чтобы он отличался от иерархии папок 'BigProject', иначе я бы просто выбрал / BigProject / tags.

В этом случае создайте папку с именем используемого вами тега, 1.0.0.

Теперь у вас есть:

svn://localhost/Releases/BigProject/1.0.0

Оформить заказ в этой папке. Добавьте свойство svn, svn: externals, с содержанием:

svn://localhost/BigProject/Project1/tags/1.0.0
svn://localhost/BigProject/Project2/tags/1.0.0
svn://localhost/BigProject/ProjectX/tags/1.0.0

Теперь вы можете проверить svn: //localhost/Releases/BigProject/1.0.0, чтобы все ваши проекты имели тег 1.0.0.

0 голосов
/ 17 марта 2010

svn help говорит:

usage: copy SRC[@REV]... DST                                             

When copying multiple sources, they will be added as children of DST,
which must be a directory.                                           

  SRC and DST can each be either a working copy (WC) path or URL:
    WC  -> WC:   copy and schedule for addition (with history)
    WC  -> URL:  immediately commit a copy of WC to URL
    URL -> WC:   check out URL into WC, schedule for addition
    URL -> URL:  complete server-side copy;  used to branch and tag
  All the SRCs must be of the same type.

Вы можете попробовать скопировать WC -> WC, а затем зафиксировать.


Edit:
WC/dir WC/dir2 -> URL похоже тоже работает Таким образом, у вас будет только trunk для оформления заказа.

svn copy dir1 dir2 https://mysvnserver/svn/dy_test/tags/1.0.0 -m "tag 1.0.0."


Редактировать2: добавлено --parents : make intermediate directories

svn copy --parents dir1 dir2 https://mysvnserver/svn/dy_test/tags/1.0.0 -m "tag 1.0.0."
0 голосов
/ 17 марта 2010

Я чувствую, что это невозможно. И если честно, я не понимаю, почему так должно быть. Чего вы пытаетесь достичь (помимо того, что N тегов созданы в той же ревизии)? Или по-другому: зачем тебе это нужно? Идея тегов (в определенной степени) состоит в том, чтобы освободить вас от запоминания номеров ревизий и позволить вам «собрать» смешанные ревизии, которые, я думаю, указывают на то, что вам не нужно достигать того, что вы пытаетесь.

Чтобы получить «Tag 1.0.0», вам нужно просто оформить заказ Project1..N/tags/1.0.0 и не беспокоиться о номерах ревизий.

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

К сожалению, я не совсем понимаю второй вопрос. Что вы подразумеваете под аналогичными модификациями ? Похожи друг на друга или похожи на первый вопрос?

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