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

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

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

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

EDIT: Справочная информация:

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

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

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

6
copy pvcs svn transactions

8 ответов

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

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

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

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

5

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

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

7

Вы можете использовать: 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
6

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

но я думаю, что вы можете сделать аналогичную вещь для разработки деталей в subversion с немного tweaking:

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

/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.

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

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

3

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

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

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

здесь у нас есть:

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

Если все проекты были в своих собственных репозиториях, внешние svn могут сделать трюк

0

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

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

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

0

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

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

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

0