?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
ignore-on-commit для TSVN
nyaload
_winnie
У нас редакторы постоянно меняют некоторые файл настроек под svn. Коммит этого файла от одного дизайнера ломает работу остальным. Исправить это в чужом редакторе ммм сложно. Игнорировать файл тоже нельзя (он должен быть в репозитории, заигнорить то что в репозитории - не влияет на работу TSVN).

Вот как можно сделать, что бы изменённый файл не отмечался автоматом галочкой в TortoiseSVN:

rem add options.xml to *local* ignore changelist, if not was already here
(svn stat %1 | findstr ignore-on-commit > NUL) || svn changelist ignore-on-commit %1

Увы, это влияет только на локальные настройки TSVN. Что бы распространить эти настройки у всех, я засунул эти общие настройки в батники запуска редактора и игры.
Tags: ,


  • 1
Можно хранить в репозитории не конфиги, а шаблоны (болванки, сэмплы, генераторы) конфигов с проставленными умолчаниями. Фактические конфиги не версионируются, т.е. хардкодные сроки типа тестовых айпишников, демонстрационных баз данных, локальных путей не распространяются на других разработчиков с другим окружением. В случае, когда изменения требуется распространить (скажем, добавилась новая секция конфига), они вносятся в шаблонный конфиг, и доступны всем после апдейта. Профит — при экспериментах с настройками рабочая папка остаётся «чистой» (зелёная галочка), нет интерференции с другими разработчиками. Минус — нужно автоматически генерировать (в простейшем случае, копировать с новым именем) фактические неверсионируемые конфиги по шаблонным конфигам при чистом чекауте (или выносить правило генерации в скрипт сборки). Другой минус — нет уведомления об обновлении шаблонного конфига.

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

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

>Можно хранить в репозитории не конфиги, а шаблоны (болванки, сэмплы, генераторы) конфигов с проставленными умолчаниями.
> Минус — нужно автоматически генерировать (в простейшем случае, копировать с новым именем) фактические неверсионируемые конфиги по шаблонным конфигам при чистом чекаут
Да, я думаю, так лучше. Мне ещё кажется, что если такое надо сделать в офисе на несколько десятков человек в разгар рабочего времени - потребуется больше возни или со скриптами и их тестированием, или криков "после обновления обязательно скопируйте файлик".

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

У меня такой опыт, всё что можно забыть - творческие люди забывают :) Всё можно починить скритами, кроме слишком большого количества заплаточных скриптов.


Описанный выше способ — это, по сути, диффы/патчи вручную. Вероятно, есть способ использовать непосредственно соответствующие GNU'тые тулзы.

>потребуется больше возни

Зависит ещё и от того, часто ли меняется формат конфигов, или добавляются глобальные настройки. Если не очень, то можно и ручной батник сделать. Если часто, то, имхо, лучше добавить в скрипты сборки правило, где таргет (неверсионируемый конфиг) будет при устаревании строиться по «исходнику» конфига.

>>А вообще, пусть ваши дизайнеры создают приватные ветки, и коммитят туда сколько влезет, лишь бы синхронизироваться с транком не забывали.
>У меня такой опыт, всё что можно забыть - творческие люди забывают :)

Общая проблема заключается в том (Кэп настороже!), что в конфиге в рамках одного файла находятся секции двух противоречивых типов: 1) глобальные, которые нужно хранить, шарить, время от времени обновлять; 2) локальные, которые неплохо бы хранить, но нельзя шарить. Дельта-конфиги просто разносят эти типы настроек по двум разным файлам.

То же касается и операции «коммит-в-транк» в Subversion — она перегружена, так как выполняет сразу две (часто противоречивые) функции: 1) сохранение ревизии, 2) публикация ревизии. Чтоб подобные противоречия решать, как раз и придумано ветвление в системах контроля версий.

Проще хранить в репозитории файл конфигурации с одним именем (скажем, my.cfg-global), а в программе использовать конфиги из файла с другим именем (скажем, my.cfg). При первом запуске программы (или в случае отсутствия файла my.cfg) копировать my.cfg-global в my.cfg.

Так я об том и говорю.
Программа использует неверсионируемый app.config, в репозитории же лежит app.config.sample.
При чистом чекауте скрипт копирует все *.config.sample в *.config.

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

И, ещё раз, остаётся проблема: редактируемый неверсионируемый конфиг — он же сам по себе не узнает, что изменились глобальные настройки в *.config.sample.

> Просто я попытался сразу обобщить

Это да, обобшить лом до карданного вала - это наше всё. Сам грешен. :)

> редактируемый неверсионируемый конфиг — он же сам по себе не узнает, что изменились глобальные настройки в *.config.sample

Оно и к лучшему, что не узнает - поскольку там не глобальные, а дефолтные настройки. Глобальные настройки лучше хранить в отдельном файле и вообще не давать менять рядовым исполнителям - только техподдержке|лиду. :)

Под «глобальными настройками» я имею в виду «общеприменимые». Скажем, установлена умеренная детализация логгера, она же и должна пойти в продакшн. А «локальными настройками» я называю те настройки, которые нужны в течение какого-то отрезка времени какому-то разработчику; скажем, сверхподробная детализация логгера.

Edited at 2010-07-06 01:49 pm (UTC)

игноры можно запихнуть прямо в репозиторий на уровне свойств папки.

если заигнорить файл svn:ignore в репозитории, то TSVN его предлагает коммитать, и люди рано или поздно коммитят. Вероятность не ошибиться стремится экспоненционально к нулю, от времени и количества людей.

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

И вообще подходи, так обсудим, если интересно.
А то через коридор сидим, а общаемся тута.

Так есть же пропертя svn:ignore
В тортузе выглядит так, что файл не попадает в список commit.
Повсеместно используем, проблем никаких.

Обычный игнор не помогает для тех файлов, которые должны лежать под svn (и браться по checkout).

Это не очень хороший способ, лучше делать шаблоны, как советуют в svn-book и в комментах выше. Зато показанный здесь способ - легче, когда надо всё сделать побыстрей (за полчаса, а не за полдня).

Хм. Я делаю файлы c setting'ами тулзов always-writable, keep 1 ltest revision, ну и соответственно они никогда не субмитятся. Никто и не подозревает куда и как настройки сохраняются :)

Правда в перфорсе идеология другая -- субмитишь то только то что взял на chek-out, а settings на check-out брать не нужно ибо и так writable.

Если файл _никогда_ не сабмитится, то зачем его вообще класть под перфорс? :)

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

У нас вот последний вариант местами, да... :(

> Если файл _никогда_ не сабмитится, то зачем его вообще класть под перфорс?

Чтобы первоначальные настройки редактора были в репо а не "все знают что их нужно скопировать вон оттудова".

А несчастные пользователи вполне могут сделать resolve, ну или позвать того кто может -- изредка это не страшно :)

Можно запретить коммитить этот конкретный файл конкретным ненадежным личностям.

  • 1