Subversion: можно ли выполнить несколько операций копирования в одной ревизии?
Из того, что я понимаю о транзакциях в Subversion, это должно быть возможно в принципе, но я не знаю ни одного инструмента, который бы его поддерживал.
Исходным фоном является то, что мы обсуждаем переход от измерений PVCS к Subversion, и основной функцией, которая в Subversion названа отсутствующей, является "Детали проектирования". Проектная часть - это произвольная коллекция файлов, которые могут обрабатываться вместе, например, все исходные файлы, необходимые для подпроекта.
Одной из идей заменить это является операция копирования в Makefile, которая копирует соответствующие файлы в ветку. Но если все файлы копируются отдельно, это может привести к большому количеству ревизий, которые могут загромождать историю, поэтому было бы неплохо этого избежать.
РЕДАКТИРОВАТЬ: Еще немного справочной информации:
Проект состоит из нескольких (5-10) подпроектов, которые выпускаются отдельно, но имеют общие исходные файлы и внешние библиотеки, импортированные из других проектов.
Одна из причин, приведенных для частей проекта, - это ограничение зависимостей от исходных файлов, другая - для управления продуктами подпроектов, так что все они могут быть обновлены в управлении версиями за одну операцию. Оба вида файлов несколько разбросаны по каталогам.
Нас около 5 разработчиков на проекте.
8 ответов
Вы можете сделать копии в рабочей копии и зафиксировать их сразу. Это создает только одну ревизию.
С клиентом командной строки это может выглядеть так:
svn copy file1 directory
svn copy file2 directory
svn copy file3 directory
svn commit
Основным недостатком является то, что вам нужна рабочая копия, и эта рабочая копия должна содержать исходный и целевой каталог.
Существует инструмент svnmucc, который делает именно это, не требуя рабочей копии:
Ты можешь использовать: 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
Это довольно интересно, я только что быстро прочитал на части дизайна, из того, что я могу собрать, эффективно разветвляя файлы по отдельности в произвольную структуру, вы начнете идти в мир боли, когда вы начнете объединить вещи обратно в их исходное местоположение (и объединение, вероятно, не будет сделано за один раз для всех файлов).
Но я думаю, что вы можете сделать то же самое, чтобы спроектировать части в 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 и сценариями, которые вы используете для управления ими.
Почему бы вам не поместить свой подпроект в собственный подкаталог.
Project
|
---> Subproject 1
---> Subproject 2
Files from project.
Таким образом, вы всегда можете работать над полным подпроектом.
Здесь мы имеем:
Project
|
---> common Files
---> Subprojects...
Если все проекты были в своих собственных репозиториях, svn externals может сделать свое дело
Я столкнулся с похожей проблемой: как скопировать несколько файлов, разбросанных в репозитории, в тег и сделать это быстро за одну транзакцию, таким образом, за одну ревизию. Самый простой способ - создать временный каталог Working Copy, скопировать туда все необходимые файлы, а затем скопировать локальный Working Copy в удаленный репозиторий и удалить временный каталог:
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
надеюсь, это поможет.
Ваш рабочий процесс / организация кода неверна:
если у вас есть общий код между отдельными пакетами, он явно принадлежит к отдельному. одно дерево в упаковке.
объединение нескольких пакетов (определенных версий) в какую-либо среду (например, более крупный программный продукт, состоящий из нескольких, возможно, необязательных) компонентов относится к отдельному уровню выше: дистрибутиву и обрабатывается инфраструктурой управления пакетами дистрибутива.