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

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

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

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

Например, предположим, что у вас есть хранилище с двумя программными проектами.

Рисунок 2.6. Файловая система хранилища

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

Адреса URL хранилища

Таблица 2.1. URL для доступа к хранилищу

Также, пользователи схемы file:// на платформе Windows вынуждены использовать неофициальный « стандарт » синтаксиса для доступа к хранилищам, находящимся на той же машине, но на дисках, отличных от текущего рабочего диска пользователя. Будет работать любой из двух приведённых ниже синтаксиса путей URL ( X обозначает диск, на котором находится хранилище):

Обратите внимание, в URL используется обычная (прямая) косая черта, хотя в исходной (не URL) форме путей в Windows используется обратная косая черта.

Вы можете получить доступ к хранилищу FSFS через сетевой ресурс, но это не рекомендовано по разным причинам:

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

Вы должны настроить разрешения на доступ именно так, как нужно. SAMBA особенно сложен в этом отношении.

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

Ревизии

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

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

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

Рисунок 2.7. Хранилище

Общие номера ревизий

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

Как рабочие копии отслеживают хранилище

на какой ревизии основан ваш рабочий файл (это называется рабочая ревизия файла), и

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

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

Файл не изменялся в рабочей папке, и в хранилище не фиксировались изменения этого файла со времени его рабочей ревизии. Команды фиксировать (commit) и обновить (update) ничего делать не будут.

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

Файл был изменён в рабочей папке, и в хранилище не фиксировались изменения этого файла со времени его базовой ревизии. Существующие локальные изменения не были зафиксированы в хранилище, поэтому команда фиксировать (commit) для файла преуспеет в опубликовании ваших изменений, а команда обновить (update) ничего делать не будет.

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

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

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

Источник

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.

Источник

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 в коде 1С 7.7

Хочу поделиться способом подстановки в код 1С 7.7 номера ревизии и других значений из рабочей копии SVN.
Реализовать нижеописанное навеяло статьей, автору выражаю благодарность за вдохновение.

Предыстория

Причина

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

По заданному шаблону получаем данные о рабочей копии с помощью TurtoiseSVN, на выходе получаем другой файл-шаблон со структурой «МаскаДляПоиска» = «ЗначениеДляЗамены» для программки-парсера.
Парсер перебирает файл-шаблон и ищет совпадения в файле с кодом. Маской для поиска является название функции. Если таковая находится — заменяется следующая после нее строчка (которая возвращает значение функции) на «ЗначениеДляЗамены» из шаблона. После этого файл передается дальше на компиляцию. Далее из магазина выгружается файл с данными и передается в офис, где полученная информация обрабатывается и консолидируется.

Реализация

Вызов getRevision.bat был добавлен в Build.bat, а так как Build.bat предварительно копирует исходники в отдельную папку BUILD и она же указывается параметром для getRevision.bat подмена значений никак не отражается в папке REPO с исходниками и соответственно изменения не попадают в SVN, что для меня очень удобно.
По просьбе коллег был создан отдельный bat’ник — СompileSVN.bat
Как можно понять по называнию, он делает подмену значений в оригинальной папке с исходниками и запускает компиляцию. Его содержимое:
Compile.bat остался без изменений

Чтобы парсеру было что искать, вставляем в глобальный модуль функции «пустышки»

Результат

Если запустить CompileSVN.bat и посмотреть изменения в коммите, можно увидеть следующее:
(некоторые данные изменены):

Так же в глобальный модуль была добавлена процедура для выгрузки данных из магазина

Выгружается такой вот файлик (некоторые данные изменены):

Файл записывается в папку для обмена, потом передается на FTP сервер. Оттуда наша база «Копирка» будет собирать эти файлы и полученные данные записывать в базу.

Для удобства коллективного обновления скриптов был использован инсталятор inno setup, подробно описывать его нет смысла — там все просто и есть хороший help.

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

Источник

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

Источник