Публикация

Работа в конфигурации с SVN

В этой статье будут описываться различные особенности работы с SVN.
При выполнении операции "Обновить из SVN"
1. Проверяется готовность локальной папки (путь к папке указывается в поле рабочего пространства "Путь к рабочей копии")
2. Обновление локальной папки из SVN до ревизии указаной в рабочем пространстве (SVN конфликты решаются в пользу SVN сервера)
3. Наложение изменений из БД, на этом шаге все изменения из БД отображаются на файловую систему (SVN конфликты решаются в пользу локальных изменений пользователя)
4. Обновление измененной локальной папки из SVN до последней ревизии сервера (SVN конфликты решаются в пользу локальных изменений пользователя)
5. Загрузка данных в БД.
В результате этой операции пользователь НЕ теряет своих изменений в БД!

При выполнении операции "Зафиксировать в SVN"
1. Выполняется проверка когда была скомпилирована конфигурация, и если после последней компиляции были изменения и пользователь пытается зафиксировать неоткомпилированые изменения, то выполняется компиляция конфигурации
2. Проверяется возможность фиксировать Сustom-пакеты
3. Проверяется готовность локальной папки
4. Выполняется проверка необходимости обновления конфигурации. Если необходимо обновление конфигурации (версия ревизии рабочего пространства отличается от номера ревизии на SVN сервере) то выполняется операция "Обновить из SVN". В этом случае операция прерывается. После окончания обновления необходимо повторно выполнить действие "Зафиксировать в SVN".
5. Если обновление конфигурации не нужно, то выполняется обновление локальной папки из SVN до ревизии указаной в рабочем пространстве (SVN конфликты решаются в пользу SVN сервера)
6. Наложение изменений из БД, на этом шаге все изменения из БД отображаются на файловую систему (SVN конфликты решаются в пользу локальных изменений пользователя)
7. Загрузка данных на SVN сервер (SVN конфликты решаются в пользу локальных изменений пользователя)

Для просмотра изменений которые будут залиты на SVN сервер
Перед выполнением действия "Зафиксировать в SVN" выполнить "Обновить из SVN".
С помощью клиента TortoisSVN посмотреть изменения файловой среды по пути указаному в поле рабочего пространства "Путь к рабочей копии".
Если у пользователя устаревшая версия данных в БД или какие-то ошибки, это обычно отображается как измененные или удаленные файлы элементов конфигурации с которыми пользователь не работал.
В этом случае необходимо сохранить свои измененные схемы (используя операцию Импорт) и выполнить в системе операцию "Очистить", после чего вернуть измененные схемы в очищеную конфигурацию (используя операци Экспорт) выполнить "Компилировать" и при успешном завершении операции - "Зафиксировать в SVN".

Переименование элементов конфигурации
На данный момент в конфигурации запрещается переименовывать элементы конфигурации используя существующие имена.
Примеры запрещенных переименований:
Исходное состояние: схема1 название_А, схема2 название_В
Изменения: схема1 название_В, схема2 название_А
или
Исходное состояние: схема1 названиеА
Изменения: схема1 названиеА - удалена, схема2 названиеА -добавлена
Такие переименования приводят к потере данных при сохранении изменений на SVN сервере

Смена Uri репозитория для рабочего пространства
При смене в рабочем пространстве значения поля "Uri репозитория" выполняется очистка номера ревизии для рабочего пространства и очищается локальная папка указаная в поле "Путь к рабочей копии", если есть доступ к этой папке. В результате контент БД не удаляется, но теряет свою актуальность. У пользователя еще есть возможность сохранить свои изменения в схемах используя операцию Импорт.
После смены "Uri репозитория" пользователь обязан выполнить операцию "Обновить из SVN". В результате этой операции пользователь потеряет все свои локальные изменения и получит последнюю версию пакетов и их содержимого с указаной ветки SVN сервера.
Эта операция приводит к потере локальных изменений пользователя в БД!

Нравится

Поделиться

6 комментариев

Доброго дня!

Не новая тема, но хотелось бы уточнить порядок действий, чтобы не создать себе проблем...
1. Итак, что есть:
1.1. локальный сайт, конфигурация настроена на svn (назовем его svn1), в конфигурации создано допустим два новых пакета.
1.2. Облако без изменений.

2. Что нужно:
2.1. поменять указанный svn для сайта 1.1 на другой svn2 (по ряду причин нужно использовать другой svn2 сервер, назовем эти причины чисто техническими, например svn1 сервер и машина стали физически недоступны). При этом перенести содержимое ветки svn1 в svn2 и естественно сохранить все в конфигурации
2.2 этот новый сервер открыть в мир и настроить на работу с ним облака

По 2.2 понятно. Если пакеты в svn2 есть, то я их легко загружу в облако.
По 2.1 похоже меня ждет проблема, судя по

"Адасюк Валерий Викторович" написал:Смена Uri репозитория для рабочего пространства
...
После смены "Uri репозитория" пользователь обязан выполнить операцию "Обновить из SVN". В результате этой операции пользователь потеряет все свои локальные изменения и получит последнюю версию пакетов и их содержимого с указаной ветки SVN сервера.
Эта операция приводит к потере локальных изменений пользователя в БД!

Почему бы это не добавить в инструкцию?

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

"Юсупов Марат" написал:Почему бы это не добавить в инструкцию?

О какой инструкции идет речь? Об инструкции на академии?

"Юсупов Марат" написал:Чую что именно думая, что у каждой схемы, детали, страницы есть id в метаданных, я могу смело их переименовывать.
Оказывается - нельзя. Верно?

Конечно, нельзя. Всё верно.

Тогда как быть с деталями который создаются при помощи мастера деталей?
ПрефиксSchema1Detail
ПредиксПерфиксНазваниеСхемы1Page.

Если их нельзя переименовывать.

Марат,

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

Насколько мне известно, то имя схемы изменить можно.

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

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

Алла, но опять таки то что написано наверху не говорит об id.

<strong>Переименование элементов конфигурации</strong>
На данный момент в конфигурации запрещается переименовывать элементы конфигурации используя существующие имена.
<strong>Примеры запрещенных переименований:</strong>
Исходное состояние: схема1 название_А, схема2 название_В
Изменения: схема1 название_В, схема2 название_А
или
Исходное состояние: схема1 названиеА
Изменения: схема1 названиеА - удалена, схема2 названиеА -добавлена
Такие переименования приводят к потере данных при сохранении изменений на SVN сервере

На сегодня мы подняли новую платформу и БД, и ни разу не переименовывали схемы как есть сейчас. Тьфутьфутьфу пока нормально все)))

Либо делается это так.
При создании через мастер деталей, созданные схемы и детали с названием которая система создала:
1. фиксировать(commit) в SVN
2. снять блокировку
3. Через тортилу проверить , а нет ли коммита?
4. Если нет блокировки то п.7
5. Если файл заблокирован, снять блокировку через тортилу, удалить файлы из временной папки TEMP*SVN
6. В конфигураторе обновить пакет
7. если п.3 нет блокировки, переименовывать схемы
8. повторить п.1

Это догадки, но надо тестировать

Показать все комментарии