что такое ревизия в 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

Источник

Subversion

Введение

Subversion (сокращенно SVN) — система управления версиями (Version Control System, VCS). Обычно тулзы этого рода считаются теми, кто с ними не знаком, чем-то нужным только большим командам программистов. Но на самом деле, они крайне полезны даже одиночке, и даже не программисту — всем, кому приходится редактировать какие-либо файлы. Так, я встречал весьма восторженное описание системы CVS (идейный предшественник SVN и первая свободная VCS — благодаря чему она до сих пор достаточно распространена) от какого-то то ли журналиста, то ли писателя, ее использовавшего.

Почему SVN?

Что такое SVN?

Subversion — централизованная система управления версиями — то есть, она хранит файлы и их историю в центральном хранилище, называемом репозиторий. Subversion ориентирована на работу с файлами — она следит за изменениями файлов, отданных под ее контроль, и сохраняет их. Также, в отличие от CVS, SVN следит и за папками. Подробней об отличиях (и вообще о системе) можно почитать тут, раздел «Subversion и CVS».

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

И как с этим работать?

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

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

Если над проектом работает более одного человека — будут неизбежно возникать конфликты. Допустим, есть два пользователя — Гарри и Салли (да, я сперва заглянул в SVN Book, но картинки оттуда тянуть лень). Они работают с одним и тем же файлом А.

Экспорт

Ветви

SVN поддерживает идеологию ветвей — когда независимо от основной линии развития проекта разрабатываются побочные, при этом изменения могут копироваться между ветвями. Правда, поклонники Git утверждают, что поддержка ветвей в SVN говно и недостойна таковой называться. Возможно и правы, Git и правда выглядит очень любопытно и обеспечивает контроль над туевой хучей ветвей ядра Linux (для которого и был создан Торвальдсом).
С ветвями я не работал, поэтому рекомендую почитать на эту тему SVN Book.

Создание репозитория

Чтобы работать с репозиторием, нужен, как ни странно, сам репозиторий. Хорошо, когда подключаешься к существующему проекту — он уже есть. А если проект начинаешь сам? Тогда его необходимо создать. И тут есть два варианта — локальный и удаленный репозитории.

Создание локального репозитория

Прежде всего — надо создать папку под репозиторий. Затем — создать в ней репозиторий командой create (точнее, в случае официального клиента — svnsdmin create). При этом нужно выбрать тип репозиторий — FSFS или BDB. Не буду вдаваться в подробности, но лучше создать FSFS (а свежие версии так и делают по дефолту). Кроме того, BDB репозиторий нельзя создавать на нелокальной файловой системе (например, на подмонтированном сетевом ресурсе) — через некоторое время он просто сломается.
URL для созданного локально репозитория — file:///path/to/repository, например, если репозиторий в папке C:\MyRepository, то его URL — file:///C:/MyRepository.
С локальным репозиторием клиент SVN работает непосредственно — сервер не требуется. Для обслуживания репозитория (как локального, так и выведенного в сеть сервером) предназначена утилита svnadmin.

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

Немного о содержимом этой папки. Вообще, хранить файлы в репозитории можно как угодно, но есть рекомендованный стандарт. Согласно ему в репозитории при импорте создаются пустые папки trunk, branches и tags. Если планируется хранить в репозитории несколько проектов — то для каждого создается папка, а уже в этих папках — папки trunk, branches и tags.

Удаленный репозиторий

Удаленный репозиторий может быть в локальной сети и в интернете.
В первом случае (а также во втором, когда репозиторий на своем хостинге) на хосте репозитория следует поднять и настроить SVN сервер — родной svnserve (говорят, крайне дыряв) или на основе apache+webdav или иной SVN-плагин. Но это тема не этой статьи, да и не знаком я с ней.
Но есть еще один вариант — это SVN-хостинги. Их немало, как платных, так и бесплатных. Они предоставляют уже готовый репозиторий, а если и нет — то сами расскажут, как его создать. Лично я пользуюсь хостингом от гугла. Остальных — доставит он же 🙂
Репозиторий в интернете позволяет синхронизировать свои рабочие копии на разных компах, а также работать над проектом вместе с другими людьми, возможно на другом конце мира. А также, при желании — предоставлять всем желающим доступ (на чтение) к самой свежей версии исходников.

Круто. А где взять?

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

Лично мне нравится TortoiseSVN — это GUI-клиент (т.е. в отличие от оболочки он выполняет действия сам, а не передает их консольной программе svn), выполненный как расширение Проводника Windows. Вся работа с ним производится через контекстное меню Проводника. Также совместимо с Total Commander и ему подобными файл-менеджерами (теми, которые запрашивают иконки файлов у винды и умеют показывать контекстное меню Проводника). Поклонникам FAR’а и других операционок могу порекомендовать только гугл. Также TortoiseSVN показывает состояние файлов, накладывая оверлеи на их иконки. Благодаря этому с первого взгляда видно состояние рабочей копии — модифицированные файлы, конфликты и так далее.
Стоит также обратить внимание на то, что TortoiseSVN добавляет свои пункты в контекстное меню, показываемое при перетаскивании файлов/папок правой кнопкой мыши. Там такие полезные команды, как Export, Copy, Move.
Алсо, в разделе языковых пакетов к TortoiseSVN имеется годный мануал в PDF, на русском. Рекомендую почитать, это своеобразный аналог SVN Book для TortoiseSVN.

Настройки TortoiseSVN

Настройки вызываются через контекстное меню проводника, вызванное на любом объекте, пункт TortoiseSVN->Settings. Их там довольно много, опишу основные.

Здесь следует настроить Global ignore pattern — список масок файлов, которые SVN будет игнорировать — т.е. не предлагать их добавить, зафиксировать и т.д. Сюда следует внести различные временные файлы — на скриншоте, например, внесены файлы, создаваемые Delphi версий по 7-ю. Здесь же можно поменять язык, русский поддерживается — но не гарантирую совпадение терминологии, т.к. пользуюсь английской версией.

Здесь внимания заслуживает Status cache. Выбранный вариант обеспечивает рекурсивную проверку статуса — папка будет помечена как модифицированная даже если модифицированный файл в одной из ее подпапок.
При снятой галочке «Show overlays and context menu only in explorer» можно использовать TSVN из менеджеров вроде Total Commander.
Галочки Show overlay for позволяют отключить назойливые метки на файлах, не находящихся под присмотром SVN.
Галочки в поле Drive Types позволяют отвадить SVN от проверки на модификации медленные носители и флешки (последнее — чтобы оно не мешало их извлекать), а также от заданных дисков.

На вкладке Network можно настроить доступ к сети и выбрать клиент для SSH, но у меня там значения по умолчанию (разве что, ЕМНИП, я вручную указал использовать прилагающийся к TortoiseSVN TortoisePLink.exe как клиент SSH).

На вкладке Saved data можно почистить истории и сохраненные данные аутентификации.

На вкладке Hook scripts можно добавить программы, срабатывающие при определенных событиях. У меня там, например, внесен скрипт, срабатывающий после обновления одной из РК.

На остальных вкладках (кроме рассмотренных далее) преимущественно настройки вида и поведения. Можно настроить их на свой вкус или удовлетвориться дефолтными.

Свистелки и перделки

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

Внешние Diff/Merge

Хотя к TortoiseSVN прилагается родная программа TortoiseMerge, мне больше нравятся WinMerge для сравнения файлов (он подсвечивает изменения внутри строк, позволяет редактировать файл прямо в нем и умеет подсвечивать синтаксис для многих языков, но не умеет сравнивать три файла) и KDiff3 (удобная программа для сравнения и слияния трех файлов, изначально созданная под KDE). Кроме них интерес могут представлять Beyond Compare, Structured Difference Viewer, утилиты Diff/Merge из состава Perforce и Borland StarTeam (или как его там, не помню уже) — но из них бесплатны только две последние.

Настраиваются эти утилиты в разделе External Programs, в прилагаемом хелпе есть командные строки для многих распространенных программ. В моем случае это
для обоих вариантов на вкладке Diff и
для вкладки Merge.

Интеграция с багтрекерами

Осуществляется плагинами, список их можно найти на сайте TortoiseSVN. После установки плагина его можно подключить к соответствующей РК на вкладке Hook Scripts->Issue Tracker Integration.

CommitMonitor

Пара глазок, которые сидят в трее и периодически проверяют указанные репозитории на наличие обновлений. Иногда полезно. Обитает вместе с другими полезняшками в разделе Other Tools сайта TortoiseSVN.

Источник

Контроль версий в 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, но не зафиксированные в нем.

Источник