Что такое ревизия в svn

Как работать с ветками

Создать новую ветку очень просто. Как следует из талмуда, делается это командой copy. Допустим, мы разрабатываем некий проект — BUMP (Большой Афигенный Мега Проект). Для нашего случая, нужно выполнить такую команду:

s vn switch svn://svnserver/var/bump/branches/my-branch

Для того что бы проверить в какой ветке находитесь сейчас

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

Копирование изменений между ветками

Итак, посомтреть изменения из транка можно такой командой:

Получаем, например, такой вывод:

— Merging r4107 into ‘.’:
U db/queries.txt
U ejb/src/main/java/ru/bump/action/folder/MoveFolderActionLocal.java
U ejb/src/main/java/ru/bump/action/user/UserRegistrationAction.java

Это означает что в ревизии r4107 изменилось 3 файла. Отлично, все правильно, копируем изменения

Число 4108 это номер текущей ревизии. Получить его просто. Достаточно выполнить команду svn up.

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

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

/www/bump$ svn log | grep merged
merged from trunk r4106:4108

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

Завершение работы над задачей

Если работа над задачей завершена, вам нужно

* Слить свои изменения в транк
* Удалить свою ветку что бы не мешалась

Сливаем в транк той же командой merge. Для этого выясняем ревизию создания ветки, и свитчимся в транк.

svn switch svn://svnserver/var/bump/trunk

После этого копируем изменения из своей ветки

#svn up
At revision 4155

#svn merge svn://svnserver/var/bump/trunk@4155 svn://svnserver/var/bump/branches/my-branch@4155

Если все прошло нормально, нет никаких конфликтов и доделать ничего не нужно, комитим изменения в основную ветку, а свою ветку можно теперь удалить. Она совсем не отличается от транка, и в случае надобности мы всегда сможем создать еще одну ветку. Да и стоит помнить что наша ветка конечно же не удаляется физически, просто она удаляется из HEAD, но в ранних ревизиях мы всегда сможем её отыскать, и при необходимости востановить. Так что смелее:

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

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

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

Источник

SVN hooks: изменение комментария к ревизии

Не секрет, что по умолчанию изменение текста комментария к ревизии в SVN не разрешено. Пост предназначен для тех, кто хочет сделать это возможным, но не знает как.

Для начала немного освежим память

Что такое hook.

Нет, это не фильм Спилберга, мы же на хабре. Это крючок, на который поймали событие 🙂 Просто програмка, которая запускается при возникновении определенного события в системе версионного контроля. Поддерживаются они не только SVN, поэтому можете поиграться с хуками например в GIT.
Если в корне вашего репозитория есть папка hooks, знайте — это и есть гнездо хуков. В этой папке могут храниться шаблоны хуков, названия которых соответствуют отслеживаемым событиям.

Это означает, что на базе этих шаблонов вы можете сделать свой хук. Как вы уже догадались pre-хуки срабатывают перед событием. post-хуки — после события.
* start-commit — запускается до начала транзакции, может быть использован для проверки прав.
* pre-commit — запускается в конце транзакции, но до commit, часто используется для валидации данных, например для проверки не пустых лог-сообщений.
* post-commit — запускается после транзакции, может быть использовано для отправки e-mail или для резервирования хранилища.
* pre-revprop-change — запускается до изменений в ревизии, могут быть использованы для проверки доступа.
* post-revprop-change — запускается после изменений в ревизии, могут быть использованы для отправки e-mail.
* post-lock, post-unlock, pre-lock, pre-unlock — запускаются, когда репозиторий работает с блокировками

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

Изменение комментария к ревизии

Перейдем к решению нашей задачи. Воспользуемся pre-revprop-change хуком, для того, чтобы ввести дополнительный контроль. Кроме того, следует помнить, что в хук передаются следующие параметры
1. Путь к репозиторию
2. Ревизия, свойства которой будут изменяться
3. Имя пользователя, который будет производить изменения
4. Название изменяемого свойства
5. Код действия: A (добавлено), D (удалено), или M (модифицировано)

Хук справа.

В *nix системах достаточно создать в папке hooks соответствующий файл без расширения, например pre-revprop-change

Хук слева.

В Windows файл в папке hooks должен быть исполняемым, например pre-revprop-change.bat

Если вы используете VisualSVN сервер, батник по умолчанию работать не будет. И папку hooks создавать не надо. Надо просто открыть VisualSVN Server Manager, зайти в свойства репозитория, для которого хотите создать хук, выбрать вкладку Hooks. Дважды кликните на Pre-revision property change hook и просто скопируйте туда код батника.
Дополнение: при активации хука в VisualSVN Server Manager, сервер сам создаст папку hooks и породит там стандартные шаблоны.
За наводку спасибо chemodax

Источник

SVN. Базовые команды

Начало работы

Установка редактора

Основы

Рабочие копии

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

Каждая рабочая копия содержит папку с именем .svn, известную как административный каталог (administrative directory). Файлы, находящиеся в административном каталоге, необходимы для понимания Subversion того какие артефакты содержат неопубликованные изменения, а какие являются устаревшими по отношению к актуальной версии.

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

Получение рабочей копии поддерева репозитория выполняется следующим образом:

Расположение Subversion-репозитория всегда задается в виде URL.

Публикация изменений обычно называется фиксацией (committing) и выполняется с помощью команды commit :

Для обновления локальной рабочей копии используется команда update :

Ревизии

При приеме коммита в репозитории создается новое состояние дерева файловой системы, называемое ревизией (revision). Каждой ревизии присваивается уникальный возрастающий целочисленный номер. Начальная ревизия имеет номер 0 и соответствует пустому корневому каталогу.

Номера ревизий в Subversion относятся ко всему дереву, а не отдельному файлу.

Как рабочие копии отслеживают репозиторий

Для каждого файла Subversion поддерживает два основных свойства в административном каталоге .svn/:

Используя эту информацию Subversion, при взаимодействии с репозиторием, определяет одно из 4-х состояний рабочего файла:

Смешивание рабочих копий разных ревизий

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

Обновление и комиты разделены

Смешивание ревизий дает возможность переместить определенную часть рабочей копии в истории, позволяя исследовать более ранние изменения.

Смешивание ревизий имеет ограничения

Экскурсия по Subversion

Импорт

Для импортирования нового проекта в Subversion-репозиторий используется команда import :

Ревизии: номера, ключевые слова и даты

Диапазон задается указанием номеров ревизий через двоеточие:

Номера ревизий

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

Ключевые слова ревизий

Данные ключевые слова могут использоваться только при указании локального пути, но не URL.

Даты ревизий

Поиск в диапазоне дат выполняется следующим образом:

Начальное получение рабочей копии

Каталог для рабочей копии задается следующим образом:

В этом случае рабочая копия будет располагаться в каталоге subv вместо trunk.

Простой рабочий цикл

Типичный рабочий цикл выглядит следующим образом:

Обновление рабочей копии

Обновление рабочей копии до состояния последней ревизии в репозитории выполняется командой svn update :

Буква перед артефактом означает действие выполняемое Subversion для обновление рабочей копии.

Внесение изменений

Возможные изменения в рабочей копии:

Основные команды изменения дерева приведены ниже:

Изменения, вносимые данными командами, не видны в репозитории до следующего коммита. Для внесения изменений напрямую в репозиторий можно использовать версии команд работающие с URL.

Проверка изменений

Команда svn status показывает все изменения в файлах и каталогах.

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

В первой колонке печатается код статуса файла или каталога и/или их содержимого:

Шестая колонка показывает информацию о блокировках (отличных от L в третьей колонке).

Получение статуса конкрентного артефакта выполняется следующим образом:

Смысл первой колонки остается таким же. Вторая колонка показывает номер рабочей ревизии артефакта. Третья и четвертая колонки показывают номер ревизии последнего изменения файла и имя пользователя внесшего эти изменения соответственно.

Звездочки говорят об имеющихся на сервере обновлениях.

Для получения информации о том, какие именно были внесены изменения используется команда svn diff :

Вывод команды представлен в универсальном формате (unified diff format).

Соответствующий патч (patch) можно получить вызвав:

Отмена изменений выполняется с помощью команды svn revert :

В этом случае Subversion откатит файл до оригинального состояния находящегося в административной области .svn.

Разрешение конфликтов

В приведенном выше выводе отметка файла символом C означает то, что локальные изменения пересекаются (overlapped) с изменениями пришедшими с сервера, и требуется ручное вмешательство.

При возникновении конфликта обычно происходят три вещи:

Subversion не позволит выполнить commit при наличии данных файлов.

Разрешение конфликта можно выполнить тремя способами:

После разрешения конфликта необходимо уведомить об этом Subversion вызвав svn resolved :

Данная команда удалит три временных файла, и Subversion больше не будет считать, что файл находится в состоянии конфликта.

Слияние конфликта вручную

Текст между и ======= относится к локальным изменениям, а между ======= и >>>>>>> к изменениям полученным от сервера.

Замещение рабочего файла

Редактирование по-новой

В случае отката конфликтующего файла вызов svn resolved не требуется.

Фиксация изменений

В случае наличия в репозитории изменений для закомиченного файла svn commit завершится с ошибкой:

Источник

Контроль версий в Subversion

Creatio позволяет использовать любые системы контроля версий. В этой статье мы рассмотрим применение наиболее популярной из них — Subversion (SVN).

Subversion (SVN) — это бесплатная система управления версиями с открытым исходным кодом.

Основа SVN — хранилище, которое содержит данные в форме иерархии файлов и каталогов — т. н. дерева файлов.

Возможные действия пользователей с хранилищем SVN:

Чтение данных других пользователей системы, к которым они предоставили доступ:

Изменение данных:

В одном из нижеприведенных случаев система контроля версий SVN рекомендуется к использованию для:

Для on-site приложений рекомендуется использовать Git. Работа с системой контроля версий Git описана в статье Контроль версий в Git.

Инструкция по настройке и использованию SVN содержится в документации SVN.

Основные понятия

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

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

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

Ревизия — состояние дерева файловой системы. Ревизия подразумевает весь набор изменений файлов и каталогов как единое изменение.

Фиксация изменений дерева файловой системы — это атомарная операция, которая позволяет зафиксировать ревизию.

Ревизии в хранилище можно представить в виде серии деревьев файловой системы — массива номеров ревизий, начинающегося с 0 и растущего слева направо. Под каждым номером расположено дерево файловой системы — «снимок» состояния хранилища после фиксации.

На заметку. В отличие от других систем управления версиями, номера ревизий в SVN относятся к деревьям целиком, а не к отдельным файлам.

Общая последовательность работы с файлами в рабочей копии:

Модели версионирования

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

Типы моделей версионирования:

Модель «Блокирование-Изменение-Разблокирование»

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

Особенности модели:

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

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

Блокирование может вызвать излишнюю пошаговость.

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

Блокирование может вызвать ложное чувство безопасности.

Разработчики могут одновременно работать с разными файлами, содержащими зависящую друг от друга функциональность. Каждый разработчик заблокировал свой файл и считает, что начинает безопасную изолированную задачу. Это препятствует заблаговременному обсуждению изменений, которые могут быть несовместимы друг с другом, что приведет к неработоспособности разрабатываемого решения.

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

Модель «Копирование-Изменение-Слияние»

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

Если при одновременной работе двух пользователей изменения пересекаются, то возникает конфликт.

Чтобы разрешить конфликт необходимо:

Решающим фактором при использовании этой модели является взаимодействие между пользователями.

Работа с файлами в SVN

Свойства файла:

Назначение свойств — определить состояние файла рабочей копии.

Состояния файла рабочей копии:

Не изменялся и не устарел.

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

Изменен локально и не устарел.

В хранилище не фиксировались изменения этого файла со времени его базовой ревизии. Обновление выполняться не будет. Фиксация в хранилище выполнится успешно.

Не изменялся и устарел.

Файл в рабочей папке не изменялся, но был изменен в хранилище. Файл необходимо обновить для соответствия текущей публичной ревизии. Фиксация выполняться не будет. Обновление выполнится успешно.

Изменен локально и устарел.

Файл был изменен как в рабочей папке, так и в хранилище. Попытка фиксации потерпит неудачу. Файл необходимо сначала обновить, попытавшись объединить опубликованные другим разработчиком изменения с локальными. Если SVN не сможет выполнить объединение самостоятельно, решение конфликта будет выполнять пользователь.

Рабочая копия, используемая приложением Creatio

Клиентское приложение для работы с SVN

Для работы с SVN в файловой системе рекомендуется использовать клиентское приложение TortoiseSVN версии не ниже 1.9. Оно реализовано как расширение оболочки Windows и встраивается в контекстное меню проводника Windows. Использование TortoiseSVN описано в документации по TortoiseSVN.

Если не предполагается разработка с использованием SVN, то при включенном режиме разработки в файловой системе последовательность создания пакета ничем не отличается от обычного режима.

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

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

1. Создать пакет в приложении

На вкладке Пакеты ( Packages ) раздела Конфигурация ( Configuration ) в контекстном меню выбрать действие Добавить ( Add )).

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

2. Выгрузить созданный пакет в файловую систему

Выполнить действие Выгрузить пакеты в файловую систему ( Download packages to file system ).

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

3. Создать необходимые каталоги для пакета в хранилище SVN

Чтобы создать каталоги для пакета, используя клиентское приложение для работы с SVN (например, TortoiseSvn), необходимо перейти в репозиторий, указанный в карточке пакета. Затем в репозитории создать каталог, название которого совпадает с названием созданного в приложении пакета.

Важно. В данной статье пример работы с SVN с помощью TortoiseSvn рассмотрен сокращенно. Подробные инструкции о работе с хранилищем с SVN при помощи TortoiseSvn доступны в документации TortoiseSvn.

4. Создать рабочую копию версионной ветки пакета

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

В результате каталог пакета в файловой системе Путь к установленному приложению\Terrasoft.WebApp\Terrasoft.Configuration\Pkg\sdkPackageInFileSystem станет связанным с веткой версии 7.10.0 пакета в хранилище.

5. Зафиксировать в хранилище каталог пакета

Чтобы зафиксировать каталог пакета необходимо добавить в хранилище все содержимое Путь к установленному приложению\Terrasoft.WebApp\Terrasoft.Configuration\Pkg\sdkPackageInFileSystem и выполнить фиксацию.

Последовательность установки пакета из хранилища SVN в режиме разработки в файловой системе

После включения режима автоматического применения изменений выполнять шаги 3—6 нет необходимости. Включить этот режим необходимо до установки пакета.

Далее следует повторить шаги 3—6 приведенной выше последовательности установки пакета.

Пример. В приложение Creatio в режиме разработки в файловой системе установить пакет из хранилища SVN.

На заметку. В пакете, рассматриваемом в данном примере, содержится функциональность детали с редактируемым реестром.

Алгоритм реализации примера

1. Установить пакет в файловую систему

На заметку. Для работы с Subversion (SVN) в файловой системе рекомендуется использовать клиентское приложение TortoiseSVN версии не ниже 1.8. Оно реализовано как расширение оболочки Windows и встраивается в контекстное меню Проводника. Подробная документация по использованию TortoiseSVN доступна здесь.

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

Важно. Название каталога для выгрузки содержимого пакета должно совпадать с названием пакета.

2. Установить пакет в приложение

В результате пакет будет добавлен в приложение.

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

3. Выполнить генерацию исходных кодов

Для этого в разделе Конфигурация ( Configuration ) необходимо выполнить действие Сгенерировать для требующих генерации ( Generate where it is needed ).

4. Скомпилировать изменения

Чтобы скомпилировать изменения, необходимо выполнить действие Компилировать измененное ( Compile modified items ).

5. Обновить структуру базы данных

После компиляции изменений нужно обновить структуру базы данных действием Обновить для требующих обновления ( Update where it is needed ).

6. Установить SQL-сценарии и привязанные данные (при необходимости)

Если пакет содержит привязанные SQL-сценарии или данные, то необходимо выполнить соответствующие действия для их выполнения или установки.

После успешной установки в приложении станет доступной реализованная в пакете функциональность. В приведенном примере это функциональность детали с редактируемым реестром.

На заметку. Для отображения примененных изменений может понадобиться обновление страницы с очисткой кэша.

Важно. Привязать не связанный с хранилищем существующий пакет к SVN можно только в приложении, установленном on-site. Работать с таким пакетом можно только в режиме разработки в файловой системе.

На заметку. После привязки пакета к SVN в файловой системе его можно установить в другое приложение, используя встроенные средства Creatio.

Последовательность привязки существующего пакета к хранилищу

Альтернативный вариант привязки пакета к хранилищу — через прямой запрос в базу данных. Для этого необходимо:

Алгоритм реализации примера

1. Перейти в режим разработки в файловой системе

2. Выгрузить пакет в файловую систему

В разделе Конфигурация ( Configuration ) выполнить действие Выгрузить пакеты в файловую систему ( Download packages to file system ).

3. Создать необходимые каталоги для пакета в хранилище SVN

Чтобы создать каталоги для пакета, используя клиентское приложение для работы с SVN (например, TortoiseSvn), необходимо перейти в репозиторий и создать каталог, название которого совпадает с названием пакета.

Важно. Работа с SVN с помощью TortoiseSvn рассмотрена сокращенно. Подробные инструкции о работе с хранилищем при помощи TortoiseSvn доступны в документации TortoiseSvn.

На заметку. Повторять плоскую структуру пакета в хранилище необходимо только в том случае, если в дальнейшем планируется использовать встроенные средства Creatio для работы с SVN.

4. Создать рабочую копию версионной ветки пакета

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

5. Зафиксировать в хранилище каталог пакета

В результате все содержимое пакета будет привязано к хранилищу SVN.

На заметку. Чтобы зафиксировать в хранилище SVN новые схемы пакета, необходимо повторить действия шага 5.

Альтернативный вариант реализации примера

1. В разделе Конфигурация добавить в приложение информацию о хранилище SVN

Если информация о нужном хранилище не добавлена в разделе Конфигурация приложения, то необходимо:

2. Привязать хранилище к пакету

Для этого необходимо выполнить SQL- запрос в базу данных приложения.

Здесь SDKPackages — название хранилища, а UsrUnboundPackage — название пользовательского пакета.

Важно. Чтобы изменения применились в приложении, необходимо выйти из приложения и войти в него повторно.

3. Выгрузить пакет в файловую систему

1. Обновить пакет из хранилища SVN

Для получения последней ревизии пакета необходимо использовать клиентское приложение для работы с SVN (например, TortoiseSvn).

Чтобы обновить пакет из хранилища SVN:

2. Изменить содержимое пакета

3. Зафиксировать пакет в хранилище

Чтобы зафиксировать пакет в хранилище:

Последовательность создания пакета при переходе в режим разработки в файловой системе

Общая последовательность действий:

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

Последовательность реализации примера

1. Изменить настройку defPackagesWorkingCopyPath

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

2. Создать пользовательский пакет

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

Важно. После создания пакета необходимо добавить нужные зависимости от базовых пакетов.

3. Выполнить фиксацию пакета в хранилище

4. Перейти в режим разработки в файловой системе

Важно. Также необходимо отключить использование статического контента.

После включения режима разработки в файловой системе в разделе Конфигурация на вкладке Действия появятся две кнопки:

5. Выгрузить пакет в файловую систему

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

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

6. Добавить новые элементы пакета в хранилище SVN

Добавленные элементы будут отмечены, как связанные с хранилищем SVN, но не зафиксированные в нем.

Источник