Subversion: можно ли выполнить несколько операций копирования в одной ревизии?

Question

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

Исходным фоном является то, что мы обсуждаем миграцию с PVCS Dimensions на Subversion, и основной функцией, которая в Subversion названа отсутствующей, является «Детали проекта». Проектная часть - это произвольная коллекция файлов, которые могут обрабатываться вместе, например, все исходные файлы, необходимые для подпроекта.

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

EDIT: Еще немного справочной информации:

Проект состоит из нескольких (5-10) подпроектов, которые выпускаются отдельно, но имеют общие исходные файлы и внешние библиотеки, импортированные из других проектов.

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

Мы около 5 разработчиков проекта.

Answer 1

Существует инструмент svnmucc, который делает именно это, не требуя рабочей копии:

http://subversion.tigris.org/tools_contrib.html#svnmucc_c

Answer 2

Вы можете использовать: svn copy FROM_URL1 FROM_URL2 URL_TO

Например:

svn copy svn://192.168.1.50/trunk/folder1 svn://192.168.1.50/trunk/folder2 svn://192.168.1.50/tags/MY_TAG

Answer 3

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

С клиентом командной строки это может выглядеть так:

svn copy file1 directory
svn copy file2 directory
svn copy file3 directory
svn commit

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

Answer 4

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

Но я думаю, что вы можете сделать то же самое, чтобы спроектировать детали в Subversion с небольшой настройкой:

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

/project1
 /trunk
  /doc
   /design1
   /release2
  /src
   /subproject1
   /subproject2
 /tags
 /branches
 /parts
  /part1
  /part2
  /part3

Каждая папка частей будет содержать только свойство "svn: externals", которое вводит соответствующие файлы для этой части в соответствующее подраздел, например:

svn:externals

../../trunk/src/subproject1       src/subproject1
../../trunk/doc/release2          doc/release2

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

Вы также можете создать базовые детали для своих частей, сначала разветвив весь ствол (дешево и быстро), а затем изменив внешние элементы своей части, чтобы они указывали на ответвление вместо основного ствола. Это не увеличивает размер репозитория, и ваша рабочая копия сохраняет точно такую ​​же структуру, вы просто получаете все свои файлы из ветви, а не из ствола. Любые обновления в этой части также идут вразрез с веткой - объединение изменений этой части - это просто стандартное объединение стандартной реинтеграции ветви обратно в транк, что является стандартной практикой SVN.

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

Так что, хотя subversion не предоставляет явного уровня абстракции частей, он может быть довольно точно смоделирован вручную - вы ограничены только возможностями svn: externals и сценариями, которые вы используете для управления ими.

Answer 5

Ваш рабочий процесс / организация кода неверна:

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

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

Answer 6

Я столкнулся с подобной проблемой: как скопировать несколько файлов, разбросанных в репозитории, в тег и сделать это быстро за одну транзакцию, таким образом, за одну ревизию. Самый простой способ - создать временный каталог рабочей копии, скопировать туда все необходимые файлы, а затем скопировать локальную рабочую копию в удаленный репозиторий и удалить временный каталог:

svn mkdir TMP_DIR
svn mkdir TMP_DIR\MY_TAG
svn cp --parents src\test\File.txt TMP_DIR\MY_TAG\src\test\File.txt
svn cp --parents src\test2\File2.txt TMP_DIR\MY_TAG\src\test2\File2.txt
svn cp -m "comment" TMP_DIR\MY_TAG "http://myrepohost/myrepo/tags/"
svn rm --force TMP_DIR

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

Answer 7

Если бы все проекты были в своих собственных репозиториях, svn externals может добиться цели

Answer 8

Почему бы вам не поместить свой подпроект в собственный подкаталог.

Project
   |
   ---> Subproject 1
   ---> Subproject 2
   Files from project.

Таким образом, вы всегда можете работать с полным подпроектом.

Здесь мы имеем:

Project
   |
   ---> common Files
   ---> Subprojects...