http://www.redmine.org/projects/redmine/wiki/HowTo_configure_Redmine_for_advanced_Subversion_integration
Есть 2 пути: более простой через apache/mod_dav_svn/mod_perl и более сложный "не рекомендуемый", через pam+nss
http://www.redmine.org/projects/redmine/wiki/HowTo_to_handle_SVN_repositories_creation_and_access_control_with_Redmine
http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
http://www.redmine.org/projects/redmine/wiki/HowTo_Automate_repository_creation
Показаны сообщения с ярлыком SVN. Показать все сообщения
Показаны сообщения с ярлыком SVN. Показать все сообщения
понедельник, 15 сентября 2014 г.
суббота, 15 марта 2014 г.
FreeBSD: scons: done reading SConscript files. error: setting stack size not supported:
При попытке собрать serf (для того же subversion) можно поймать баг
# make -C /usr/ports/www/serf install clean ===> Building for serf-1.3.4 scons: Reading SConscript files ... scons: done reading SConscript files. error: setting stack size not supported: File "/usr/local/lib/scons-2.3.0/SCons/Script/Main.py", line 1344: _exec_main(parser, values) File "/usr/local/lib/scons-2.3.0/SCons/Script/Main.py", line 1308: _main(parser) File "/usr/local/lib/scons-2.3.0/SCons/Script/Main.py", line 1072: nodes = _build_targets(fs, options, targets, target_top) File "/usr/local/lib/scons-2.3.0/SCons/Script/Main.py", line 1228: jobs = SCons.Job.Jobs(num_jobs, taskmaster) File "/usr/local/lib/scons-2.3.0/SCons/Job.py", line 92: self.job = Parallel(taskmaster, num, stack_size) File "/usr/local/lib/scons-2.3.0/SCons/Job.py", line 365: self.tp = ThreadPool(num, stack_size, self.interrupted) File "/usr/local/lib/scons-2.3.0/SCons/Job.py", line 280: prev_size = threading.stack_size(stack_size*1024) *** [do-build] Error code 2 Stop in /usr/ports/www/serf. *** [install] Error code 1 Stop in /usr/ports/www/serf.
воскресенье, 20 октября 2013 г.
CentOS: subversion 1.7, 1.8 от WanDisco
centos 5:
Для 5 есть только 1.7, можно скачать пакетами, можно добавить репу wandisco.
Пакетами:
http://opensource.wandisco.com/centos/5/devel/RPMS/i386/
http://opensource.wandisco.com/centos/5/devel/RPMS/x86_64/
Через репу:
cat > /etc/yum.repos.d/wandisco.repo <<EOF
[wandisco]
name=subversion 1.7
baseurl=http://opensource.wandisco.com/centos/\$releasever/devel/RPMS/\$basearch/
enabled=1
gpgcheck=0
EOF
centos 6:
пакеты можно взять тут:
http://opensource.wandisco.com/centos/6/
выбираем 1.7 или 1.8
!!!При ручной установке пакетов предварительно удаляем старый svn!
Через репу - по аналогии как для 5, подставляем нужную версию, адрес получаем после посещения сайта.
Инструкция по настройке доступа через dav (http)
http://kianmeng.org/blog/2012/12/11/subversion-1-dot-7-x-installation-and-configuration-for-centos-5-dot-x/
Можно еще через inetd, в архиве должно быть.
Для 5 есть только 1.7, можно скачать пакетами, можно добавить репу wandisco.
Пакетами:
http://opensource.wandisco.com/centos/5/devel/RPMS/i386/
http://opensource.wandisco.com/centos/5/devel/RPMS/x86_64/
Через репу:
cat > /etc/yum.repos.d/wandisco.repo <<EOF
[wandisco]
name=subversion 1.7
baseurl=http://opensource.wandisco.com/centos/\$releasever/devel/RPMS/\$basearch/
enabled=1
gpgcheck=0
EOF
centos 6:
пакеты можно взять тут:
http://opensource.wandisco.com/centos/6/
выбираем 1.7 или 1.8
!!!При ручной установке пакетов предварительно удаляем старый svn!
Через репу - по аналогии как для 5, подставляем нужную версию, адрес получаем после посещения сайта.
Инструкция по настройке доступа через dav (http)
http://kianmeng.org/blog/2012/12/11/subversion-1-dot-7-x-installation-and-configuration-for-centos-5-dot-x/
Можно еще через inetd, в архиве должно быть.
пятница, 5 июля 2013 г.
Subversion 1.8.0
Чуть запоздало:
Увидела свет система управления версиями Subversion 1.8.0
Из основных отличий - переход с NEON на SERF, который должен быть быстрее (фряшникам неактуально, серф опцией еще в 1.6 был).. Чуть улучшили мержи, FSFS. В общем, можно перейти, но я не вижу вау-фишек как в 1.7 централизация .svn
Теперь во freebsd порт devel/subversion указывает на 1.8, и если нужно сохранить 1.7 -- переходим на devel/subversion17
http://www.opennet.ru/opennews/art.shtml?num=37207
Увидела свет система управления версиями Subversion 1.8.0
Из основных отличий - переход с NEON на SERF, который должен быть быстрее (фряшникам неактуально, серф опцией еще в 1.6 был).. Чуть улучшили мержи, FSFS. В общем, можно перейти, но я не вижу вау-фишек как в 1.7 централизация .svn
Теперь во freebsd порт devel/subversion указывает на 1.8, и если нужно сохранить 1.7 -- переходим на devel/subversion17
http://www.opennet.ru/opennews/art.shtml?num=37207
среда, 15 мая 2013 г.
FreeBSD: configure: error: Subversion requires SQLite
При попытке установить svn может вылезти
configure: WARNING: no suitable sqlite found in /usr/local
среда, 6 февраля 2013 г.
svn в debian
Ставим версию от WANDisco (репа есть в заметках)
apt-get install subversion
Есть 4 метода запуска:
apt-get install subversion
Есть 4 метода запуска:
воскресенье, 27 мая 2012 г.
svn: Can't convert string from 'UTF-8' to native encoding
svn: Can't convert string from 'UTF-8' to native encoding:
...
Характерно для freebsd, поскольку он не умеет utf-8. Решение:
setenv LC_CTYPE "ru_RU.CP1251"
опционально, ломает показ файлов (ls), показывая русский где он не нужен:
setenv LANG "ru_RU.CP1251"
(как минимум работает в csh, так что можно дописать в .cshrc)
линки
http://chatlogs.jabber.ru/freebsd@conference.jabber.ru/2008/11/22.html
http://stackoverflow.com/questions/2116718/svn-error-cant-convert-string-from-native-encoding-to-utf-8
...
Характерно для freebsd, поскольку он не умеет utf-8. Решение:
setenv LC_CTYPE "ru_RU.CP1251"
опционально, ломает показ файлов (ls), показывая русский где он не нужен:
setenv LANG "ru_RU.CP1251"
(как минимум работает в csh, так что можно дописать в .cshrc)
линки
http://chatlogs.jabber.ru/freebsd@conference.jabber.ru/2008/11/22.html
http://stackoverflow.com/questions/2116718/svn-error-cant-convert-string-from-native-encoding-to-utf-8
понедельник, 12 декабря 2011 г.
SVN: некоторые особенности
Тэги
В свн тэг - это не метка на определённую ревизию, а самый обычный бранч, который делается через svn copy. Об этом надо помнить, особенно после работы с другими системами, где термины схожи, но суть разная.
Это означает некоторые особенности в работе:
1) Метки можно менять. И меняться они будут независимо от бранча. Считается неправильным, но часто применяется "пофиксить прямо сейчас";
2) Можно сделать багофикс в метке и влить его в транк;
3) если права доступа установлены индивидуально для директорий, то метка эти права не наследует;
4) трудно узнать, в какие метки вошёл файл (то же для директории);
5) если из метки создать рабочую копию и зафиксировать из этой рабочей копии какие-либо изменения, то это изменит саму метку, а не те данные, которые были помечены. Правильным способом работы «от метки» является создание рабочей копии не из метки, а из того, что является источником этой метки.
Часть информации скопирована из вики
Свойства
Такое впечатление, что свойства появились сильно позднее - работа с ними через костыли. Поиска по свойствам нет, фильтров нет, вывод свойств svn proplist - только на отдельные объекты. Штатно не сделать вывод всех директорий, для которых установлен svn:ignore, со значениями.
На самом деле со свойствами много непоняток.
Крайне неудобно, что нельзя задать в маски строки вида */*/*links.db - оно просто не работает.
svn status verbose не показывает изменения атрибутов. Точнее, М покажет, но изменился сам файл или ему поменяли какое-то свойство - непонятно.
Установка svn:executable и некоторых подобных меток нелогична, и в оф доке ни намёка как правильно делать. Суть в том, что должно быть 3 аргумента, а у нас есть только 2: имя свойства, значение свойства, файл. А какое тут значение? А любое: ON, yes, 1... Так что писать так:
svn propset svn:executable yes /path/to/file. И ещё момент: этот бит не выставляется на каталоги, только на файлы.
!!! Если делаем svn propset svn:ignore -- тут надо внимательнее вписывать первый аргумент, потому что написав "svn propset svn:ignore ON tmp/" в игнор будет записан ON, поэтому надо вписывать \* (со слэшем, чтобы шелл не перехватил)
Особенности с операциями
Добавление файлов и каталогов. Сделав svn add dir/ добавит не только этот каталог, но и всё в нём. Чтобы добавить только его (например, чтобы проставить игнор), добавлять надо так: svn add -N dir/ . Если же было по ошибке добавлено без -N, снять добавление (до коммита) можно через svn revert dir, это не тронет его содержимое, но снимет метку добавления. Но если что-то внутри локально было исправлено - тоже откатит, поэтому надо быть аккуратным и revert-ить только лишнее. Или заранее сделав бэкап, и если что-то откатило - вернуть потом на место. А вот если уже так и закоммитили -- можно сделать svn up -r xxx (на предыдущую), а потом как-то зафиксировать так.. но проще скопировать, сделать svn rm dir, коммит и вернуть файлы на место (rm их удалит при коммите). В общем, тут красивого решения не знаю. Реверта на конкретную версию нет.
Частичный коммит. Можно сделать svn ci subdir/ - это закоммитит только изменения в subdir, не затронув изменения выше.
Но также можно сделать svn up subdir - это обновит тоже только subdir, что может быть чревато - если менялось много файлов, у нас получится часть файлов ревизии 1, часть ревизии 2.. Привет странные ошибки.
Простое создание ветки
svn copy ^/trunk ^/branches/branch_name
"Да и никто не мешает сделать скрипт, наподобии:
svn copy ^/trunk ^/branches/%1
И вызывать его:
svn_branch НАЗВАНИЕ_ВЕТКИ"
отсюда
Стратегии использования svn
Для работы на svn-сервере есть команда svnlook, ей в частности можно посмотреть содержимое репы, информацию о ревизии итд.
svnlook info /path/to/repo - информация о последнем коммите
svnlook tree /path/to/repo - список файлов
Плюс для работы нужна утилита svnadmin
создание репы, проверка, дамп-рестор
И есть малоизвестная команда svnsync - создание зеркала реп
В свн тэг - это не метка на определённую ревизию, а самый обычный бранч, который делается через svn copy. Об этом надо помнить, особенно после работы с другими системами, где термины схожи, но суть разная.
Это означает некоторые особенности в работе:
1) Метки можно менять. И меняться они будут независимо от бранча. Считается неправильным, но часто применяется "пофиксить прямо сейчас";
2) Можно сделать багофикс в метке и влить его в транк;
3) если права доступа установлены индивидуально для директорий, то метка эти права не наследует;
4) трудно узнать, в какие метки вошёл файл (то же для директории);
5) если из метки создать рабочую копию и зафиксировать из этой рабочей копии какие-либо изменения, то это изменит саму метку, а не те данные, которые были помечены. Правильным способом работы «от метки» является создание рабочей копии не из метки, а из того, что является источником этой метки.
Часть информации скопирована из вики
Свойства
Такое впечатление, что свойства появились сильно позднее - работа с ними через костыли. Поиска по свойствам нет, фильтров нет, вывод свойств svn proplist - только на отдельные объекты. Штатно не сделать вывод всех директорий, для которых установлен svn:ignore, со значениями.
На самом деле со свойствами много непоняток.
Крайне неудобно, что нельзя задать в маски строки вида */*/*links.db - оно просто не работает.
svn status verbose не показывает изменения атрибутов. Точнее, М покажет, но изменился сам файл или ему поменяли какое-то свойство - непонятно.
Установка svn:executable и некоторых подобных меток нелогична, и в оф доке ни намёка как правильно делать. Суть в том, что должно быть 3 аргумента, а у нас есть только 2: имя свойства, значение свойства, файл. А какое тут значение? А любое: ON, yes, 1... Так что писать так:
svn propset svn:executable yes /path/to/file. И ещё момент: этот бит не выставляется на каталоги, только на файлы.
!!! Если делаем svn propset svn:ignore -- тут надо внимательнее вписывать первый аргумент, потому что написав "svn propset svn:ignore ON tmp/" в игнор будет записан ON, поэтому надо вписывать \* (со слэшем, чтобы шелл не перехватил)
Особенности с операциями
Добавление файлов и каталогов. Сделав svn add dir/ добавит не только этот каталог, но и всё в нём. Чтобы добавить только его (например, чтобы проставить игнор), добавлять надо так: svn add -N dir/ . Если же было по ошибке добавлено без -N, снять добавление (до коммита) можно через svn revert dir, это не тронет его содержимое, но снимет метку добавления. Но если что-то внутри локально было исправлено - тоже откатит, поэтому надо быть аккуратным и revert-ить только лишнее. Или заранее сделав бэкап, и если что-то откатило - вернуть потом на место. А вот если уже так и закоммитили -- можно сделать svn up -r xxx (на предыдущую), а потом как-то зафиксировать так.. но проще скопировать, сделать svn rm dir, коммит и вернуть файлы на место (rm их удалит при коммите). В общем, тут красивого решения не знаю. Реверта на конкретную версию нет.
Частичный коммит. Можно сделать svn ci subdir/ - это закоммитит только изменения в subdir, не затронув изменения выше.
Но также можно сделать svn up subdir - это обновит тоже только subdir, что может быть чревато - если менялось много файлов, у нас получится часть файлов ревизии 1, часть ревизии 2.. Привет странные ошибки.
Простое создание ветки
svn copy ^/trunk ^/branches/branch_name
"Да и никто не мешает сделать скрипт, наподобии:
svn copy ^/trunk ^/branches/%1
И вызывать его:
svn_branch НАЗВАНИЕ_ВЕТКИ"
отсюда
Стратегии использования svn
Для работы на svn-сервере есть команда svnlook, ей в частности можно посмотреть содержимое репы, информацию о ревизии итд.
svnlook info /path/to/repo - информация о последнем коммите
svnlook tree /path/to/repo - список файлов
Плюс для работы нужна утилита svnadmin
создание репы, проверка, дамп-рестор
И есть малоизвестная команда svnsync - создание зеркала реп
четверг, 8 сентября 2011 г.
bitrix+svn
http://dev.1c-bitrix.ru/community/webdev/user/27606/blog/978/
При разработке сколь-либо серьёзных проектов зачастую просто необходимо использовать систему контроля версий, например SVN. К сожалению, Битрикс не позволяет вести командную разработку на нескольких локальных машинах, ввиду особенностей его лицензий. Тем не менее, система контроля версий может быть использована в паре с Битрикс в качестве хранилища бэкапов.
Однако, внесение проекта на Битрикс под контроль SVN, не совсем тривиальная задача. Как минимум излишнем будет хранить файлы ядра Битрикса, так как:
1. Они не имеют никакого отношения к проекту
2. Их слишком много
3. Они постоянно обновляются
Казалось бы ничего страшного - ставим svn:ignore на папку bitrix и радуемся жизни. Но в таком случае мы не внесём под контроль SVN свои компоненты, шаблоны, настройки. Для решения этой проблемы я предлагаю воспользоваться механизмом символьных ссылок.
И так, суть решения состоит в следующем. Допустим Ваш проект располагается в каталоге /var/www/project и имеет следующую структуру папок:
* etc - каталог настроек
* bin - каталог вспомогательных скриптов
* lib - библиотеки
* www - document root сайта
Теперь действуем по пунктам:
1. Добавляем пустое дерево каталогов /var/www/project под контроль SVN
2. Разворачиваем Битрикс в /var/www/project/www
3. Проставляем свойство ignore для каталога www (svn propedit:ignore www), указывая в нём каталоги bitrix и upload
4. Коммитим (svn commit), обновляем (svn update) SVN - теперь она не обращает внимание на файлы в папках www/bitrix и www/upload
5. Переносим содержимое каталога www/bitrix/php_interface в каталог etc
6. Удаляем каталог www/bitrix/php_interface
7. Создаём символическую ссылку (находясь в каталоге www/bitrix выполняем ln -s ../../etc php_interface)
8. Пункты 5-7 повторяем для своего пространства имён компонентов, шаблонов и модулей (их можно положить в lib/componets, lib/templates и lib/modules соответственно).
После этого добавляем под контроль SVN все, видимые ей файлы в текущем репозитории и радуемся жизни.
P.S. Структуру tag/branch/trunk не стал организовывать для упрощения примера.
Чего делать категорически нельзя:
- загонять ВСЮ папку bitrix в svn
-- невменяемое количество файлов
-- папка .svn трактуется как модуль и система site update впадает в кому (в саппорт отписывался уже пару раз, обещали поправить)
-- папки .svn в сниппетах тоже трактуются как снипеты со всеми вытекающими (тоже писал в саппорт).
Если разработка под виндой, а сервер на никсах - может быть проблема с правами, владельцами.
В общем, это возможно.
При разработке сколь-либо серьёзных проектов зачастую просто необходимо использовать систему контроля версий, например SVN. К сожалению, Битрикс не позволяет вести командную разработку на нескольких локальных машинах, ввиду особенностей его лицензий. Тем не менее, система контроля версий может быть использована в паре с Битрикс в качестве хранилища бэкапов.
Однако, внесение проекта на Битрикс под контроль SVN, не совсем тривиальная задача. Как минимум излишнем будет хранить файлы ядра Битрикса, так как:
1. Они не имеют никакого отношения к проекту
2. Их слишком много
3. Они постоянно обновляются
Казалось бы ничего страшного - ставим svn:ignore на папку bitrix и радуемся жизни. Но в таком случае мы не внесём под контроль SVN свои компоненты, шаблоны, настройки. Для решения этой проблемы я предлагаю воспользоваться механизмом символьных ссылок.
И так, суть решения состоит в следующем. Допустим Ваш проект располагается в каталоге /var/www/project и имеет следующую структуру папок:
* etc - каталог настроек
* bin - каталог вспомогательных скриптов
* lib - библиотеки
* www - document root сайта
Теперь действуем по пунктам:
1. Добавляем пустое дерево каталогов /var/www/project под контроль SVN
2. Разворачиваем Битрикс в /var/www/project/www
3. Проставляем свойство ignore для каталога www (svn propedit:ignore www), указывая в нём каталоги bitrix и upload
4. Коммитим (svn commit), обновляем (svn update) SVN - теперь она не обращает внимание на файлы в папках www/bitrix и www/upload
5. Переносим содержимое каталога www/bitrix/php_interface в каталог etc
6. Удаляем каталог www/bitrix/php_interface
7. Создаём символическую ссылку (находясь в каталоге www/bitrix выполняем ln -s ../../etc php_interface)
8. Пункты 5-7 повторяем для своего пространства имён компонентов, шаблонов и модулей (их можно положить в lib/componets, lib/templates и lib/modules соответственно).
После этого добавляем под контроль SVN все, видимые ей файлы в текущем репозитории и радуемся жизни.
P.S. Структуру tag/branch/trunk не стал организовывать для упрощения примера.
Чего делать категорически нельзя:
- загонять ВСЮ папку bitrix в svn
-- невменяемое количество файлов
-- папка .svn трактуется как модуль и система site update впадает в кому (в саппорт отписывался уже пару раз, обещали поправить)
-- папки .svn в сниппетах тоже трактуются как снипеты со всеми вытекающими (тоже писал в саппорт).
Если разработка под виндой, а сервер на никсах - может быть проблема с правами, владельцами.
В общем, это возможно.
пятница, 29 июля 2011 г.
SVN: переименовываем репо
Дело в том, что нельзя просто переименовать директорию. Но и штатных методов "в 1 команду" нет, впрочем, это делается просто:
# cd /var/svn
# svnadmin create newrepo
# svnadmin dump oldrepo > oldrepo.dump
# svnadmin load newrepo < oldrepo.dump
Теперь надо проверить права (у меня работает через svnmanage и я делаю chown svn -R newrepo), скопировать из старой conf, hooks. Возможно, сделать chmod g+w
Теперь делаем в проекте svn switch --relocate и проверяем update, commit.
Можно поймать ошибку
svnadmin: File not found: transaction '0-0', path 'trunk/design'
Она может появиться, если меняли структуру дампа и создали вложенный каталог, тогда надо открыть дамп и добавить туда создание нужного каталога.
# cd /var/svn
# svnadmin create newrepo
# svnadmin dump oldrepo > oldrepo.dump
# svnadmin load newrepo < oldrepo.dump
Теперь надо проверить права (у меня работает через svnmanage и я делаю chown svn -R newrepo), скопировать из старой conf, hooks. Возможно, сделать chmod g+w
Теперь делаем в проекте svn switch --relocate и проверяем update, commit.
Можно поймать ошибку
svnadmin: File not found: transaction '0-0', path 'trunk/design'
Она может появиться, если меняли структуру дампа и создали вложенный каталог, тогда надо открыть дамп и добавить туда создание нужного каталога.
среда, 20 июля 2011 г.
SVN: изменение параметров хранилища
Во FreeBSD всё просто и логично: открываем /etc/rc.conf и вписываем:
svnserve_enable="YES"
svnserve_flags="-d --listen-port=3690"
#svnserve_data="/usr/local/repositories"
#svnserve_data="/backup/SVN"
svnserve_data="/var/svn"
svnserve_user="svn"
svnserve_group="svn"
В CentOS всё сильно хуже: чтобы понять, что куда вписывать, пришлось гуглить часа 3, а дальше методом перебора...
Для начала, создать файл /etc/sysconfig/svnserve
cat /etc/sysconfig/svnserve
#OPTIONS="svnserve_data=/var/svn"
#svnserve_data=/var/svn
#SVNREPO=/var/svn
#root=/var/svn
#SVNSERVE_OPTIONS="-d -r /var/svn/"
OPTIONS="--root=/var/svn"
Проверять, что получилось, можно через
ps auxwww|grep svn
Вдобавок, надо будет создать пользователя svn и прописать его
useradd -u 1006 -d /var/svn svn
Создав тестовый репозитарий, нас будет ждать неприятный сюрприз: владелец-рут. Исправим.
нужен wrapper
Одинаковые пути для svn:// и svn+ssh://
http://blog.stranadurakov.com/2009/08/26/how-to-remove-absolute-path-in-svn-ssh/
mv /usr/bin/svnserve /usr/bin/svnserve.bin
vi /usr/bin/svnserve
#!/bin/sh
umask 002
exec /usr/bin/svnserve.bin -r /path-to-repos "$@"
Выставим права на исполнение.
chmod 755 /usr/bin/svnserve
Вариант через xinetd (надо бы проверить, но я этот демон не признаю)
http://en.gentoo-wiki.com/wiki/Subversion/Install
Актуально для gentoo, но тут подогнать будет просто.
Шифрованные пароли
Штатно они открытым текстом. Можно подключить sasl
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-svnserve.html
Но шифроваться они будут только при передаче или и на сервере тоже?...
Если что -- про настройку в OpenSUSE
http://index01d.com/?p=9
svnserve_enable="YES"
svnserve_flags="-d --listen-port=3690"
#svnserve_data="/usr/local/repositories"
#svnserve_data="/backup/SVN"
svnserve_data="/var/svn"
svnserve_user="svn"
svnserve_group="svn"
В CentOS всё сильно хуже: чтобы понять, что куда вписывать, пришлось гуглить часа 3, а дальше методом перебора...
Для начала, создать файл /etc/sysconfig/svnserve
cat /etc/sysconfig/svnserve
#OPTIONS="svnserve_data=/var/svn"
#svnserve_data=/var/svn
#SVNREPO=/var/svn
#root=/var/svn
#SVNSERVE_OPTIONS="-d -r /var/svn/"
OPTIONS="--root=/var/svn"
Проверять, что получилось, можно через
ps auxwww|grep svn
Вдобавок, надо будет создать пользователя svn и прописать его
useradd -u 1006 -d /var/svn svn
Создав тестовый репозитарий, нас будет ждать неприятный сюрприз: владелец-рут. Исправим.
нужен wrapper
Одинаковые пути для svn:// и svn+ssh://
http://blog.stranadurakov.com/2009/08/26/how-to-remove-absolute-path-in-svn-ssh/
mv /usr/bin/svnserve /usr/bin/svnserve.bin
vi /usr/bin/svnserve
#!/bin/sh
umask 002
exec /usr/bin/svnserve.bin -r /path-to-repos "$@"
Выставим права на исполнение.
chmod 755 /usr/bin/svnserve
Вариант через xinetd (надо бы проверить, но я этот демон не признаю)
http://en.gentoo-wiki.com/wiki/Subversion/Install
Актуально для gentoo, но тут подогнать будет просто.
Шифрованные пароли
Штатно они открытым текстом. Можно подключить sasl
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-svnserve.html
Но шифроваться они будут только при передаче или и на сервере тоже?...
Если что -- про настройку в OpenSUSE
http://index01d.com/?p=9
понедельник, 27 июня 2011 г.
SVN
Практические аспекты использования svn:externals
http://habrahabr.ru/blogs/development_tools/109291/
Ветки в SVN
http://habrahabr.ru/blogs/webdev/120063/
http://habrahabr.ru/blogs/development_tools/109291/
Ветки в SVN
http://habrahabr.ru/blogs/webdev/120063/
суббота, 8 января 2011 г.
О бэкапах в SVN
Когда это имеет смысл? Для файлов, которые нельзя разделить на несколько (таких как access_log) - например дампы sql. Хранить такое просто, и в случае с svn легко синхронизировать с другими системами, а также заливать на amazon S3 - не надо перезаливать все файлы плюс оно уже сжато.
Хотя имеет смысл посмотреть и на распределенные системы контроля. Если набор данных единый, синхронизация делается просто и быстро.
Не имеет смысла использвать, когда много мелких часто изменяемых и удаляемых файлов. В итоге хранилище может раздуться до огромных размеров.
Также несжимаемые данные проще хранить отдельно.
Отдельно надо думать о бэкапах web-проектов, особенно малоизменяемых. Даже при 100к файлов добавление еще пары - процесс быстрый и если делаются простые архивы, а не инкрементные, выигрыш в месте может быть огромен. А вот распаковывание из такого хранилища с нуля может занимать часы, что приемлемо не всегда. Но получаем возможность откатиться до любой предыдущей версии и узнать, когда именно изменялись файлы.
Как вариант, хранить только ядро, а пользовательские файлы (особенно большие и бинарные) хранить отдельно в инкрементных архивах. А если движок сторонний, то можно еще уменьшить объем данных - хранить только наши модули-шаблоны, а оригинальные файлы при необходимости можно скачать с оф сайта. Хороший пример - битрикс. Неприменимо, если оригинальный движок был сильно переписан или есть привязка на данную версию.
Хотя имеет смысл посмотреть и на распределенные системы контроля. Если набор данных единый, синхронизация делается просто и быстро.
Не имеет смысла использвать, когда много мелких часто изменяемых и удаляемых файлов. В итоге хранилище может раздуться до огромных размеров.
Также несжимаемые данные проще хранить отдельно.
Отдельно надо думать о бэкапах web-проектов, особенно малоизменяемых. Даже при 100к файлов добавление еще пары - процесс быстрый и если делаются простые архивы, а не инкрементные, выигрыш в месте может быть огромен. А вот распаковывание из такого хранилища с нуля может занимать часы, что приемлемо не всегда. Но получаем возможность откатиться до любой предыдущей версии и узнать, когда именно изменялись файлы.
Как вариант, хранить только ядро, а пользовательские файлы (особенно большие и бинарные) хранить отдельно в инкрементных архивах. А если движок сторонний, то можно еще уменьшить объем данных - хранить только наши модули-шаблоны, а оригинальные файлы при необходимости можно скачать с оф сайта. Хороший пример - битрикс. Неприменимо, если оригинальный движок был сильно переписан или есть привязка на данную версию.
среда, 3 ноября 2010 г.
usvn
2 пакет - usvn
Опять CentOS. Хочу сделать отдельным хостом.
Качаем, распаковываем
# wget http://www.tigris.org/files/documents/5823/46728/usvn-1.0.1.zip
# unzip usvn-1.0.1.zip
получаем папку usvn-1.0, я ее переместил в /var/www
Но просто после распаковки инсталл будет ругаться - надо выставить права
chown -R apache:apache {config,public}
Создаем конфиг.
#vi /etc/httpd/conf.d/usvn.conf
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot /var/www/usvn-1.0/public
ServerName usvn
ErrorLog logs/usvn-error_log
CustomLog logs/usvn-access_log common
<Directory /var/www/usvn-1.0>
Options Indexes FollowSymLinks ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
# Configure access to usvn
Alias /usvn /var/www/usvn/public
<Directory "/var/www/usvn/public">
Options +SymLinksIfOwnerMatch
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
В принципе, алиас в моем случае не нужен, поэтому я просто через http://usvn обращался. Но просто в таком виде получил ошибку, что-то не могло найти.
Так что путь при инсталляции будет такой: http://usvn/install.php
Убеждаемся, что в инсталлере появилось
Good rights on "public"
Good rights on "config"
Выбираем язык, таймзону, лицензию
в Репозитарий Subversion: указываем, где мы храним репозитарии. У меня это был /var/svn
Обратите внимание: если будет какая-то ошибка (например, с правами) - пути сбросит на дефолтные!
Второй вариант:
# mkdir files
# chown apache:apache files
Дальше ему нужна БД. Зачем.. Ну раз хочет - дадим. И получаем
The PDO extension is required for this adapter but the extension is not loaded
Надо ставить.
# yum install php-pdo
И... The mysql driver is not currently installed
Ок, и его доставим
# yum install php-mysql
Создаем админа.. Решим с обновлениями..
Потом вставим в наш конфиг
<Location /svn/>
ErrorDocument 404 default
DAV svn
Require valid-user
SVNParentPath /var/svn/svn
SVNListParentPath off
AuthType Basic
AuthName "USVN"
AuthUserFile /var/www/usvn-1.0/files/htpasswd
AuthzSVNAccessFile /var/www/usvn-1.0/files/authz
</Location>
Опять CentOS. Хочу сделать отдельным хостом.
Качаем, распаковываем
# wget http://www.tigris.org/files/documents/5823/46728/usvn-1.0.1.zip
# unzip usvn-1.0.1.zip
получаем папку usvn-1.0, я ее переместил в /var/www
Но просто после распаковки инсталл будет ругаться - надо выставить права
chown -R apache:apache {config,public}
Создаем конфиг.
#vi /etc/httpd/conf.d/usvn.conf
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot /var/www/usvn-1.0/public
ServerName usvn
ErrorLog logs/usvn-error_log
CustomLog logs/usvn-access_log common
<Directory /var/www/usvn-1.0>
Options Indexes FollowSymLinks ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
# Configure access to usvn
Alias /usvn /var/www/usvn/public
<Directory "/var/www/usvn/public">
Options +SymLinksIfOwnerMatch
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
В принципе, алиас в моем случае не нужен, поэтому я просто через http://usvn обращался. Но просто в таком виде получил ошибку, что-то не могло найти.
Так что путь при инсталляции будет такой: http://usvn/install.php
Убеждаемся, что в инсталлере появилось
Good rights on "public"
Good rights on "config"
Выбираем язык, таймзону, лицензию
в Репозитарий Subversion: указываем, где мы храним репозитарии. У меня это был /var/svn
Обратите внимание: если будет какая-то ошибка (например, с правами) - пути сбросит на дефолтные!
Второй вариант:
# mkdir files
# chown apache:apache files
Дальше ему нужна БД. Зачем.. Ну раз хочет - дадим. И получаем
The PDO extension is required for this adapter but the extension is not loaded
Надо ставить.
# yum install php-pdo
И... The mysql driver is not currently installed
Ок, и его доставим
# yum install php-mysql
Создаем админа.. Решим с обновлениями..
Потом вставим в наш конфиг
<Location /svn/>
ErrorDocument 404 default
DAV svn
Require valid-user
SVNParentPath /var/svn/svn
SVNListParentPath off
AuthType Basic
AuthName "USVN"
AuthUserFile /var/www/usvn-1.0/files/htpasswd
AuthzSVNAccessFile /var/www/usvn-1.0/files/authz
</Location>
вторник, 2 ноября 2010 г.
WebSVN
Итак, ставлю разные пакеты для управления SVN и пробую... Сейчас пробовал WebSVN. Ставил так: yum install websvn enscript
Потом в конфиге поправил строку
allow from 127.0.0.1 192.168.2.
И все.. Система проста и понятна, но увы, это только показ. А мне нужна рулилка.
Если что, конфиг в /etc/websvn, поправить там скорее всего только 1 строчку надо:
$config->parentPath("/svn/repos");
это путь к репам. Все.
Чуть больше о настройке - http://debianworld.ru/articles/ustanovka-i-nastrojka-subversion-apache-websvn-v-debian-ubuntu-2/
Потом в конфиге поправил строку
allow from 127.0.0.1 192.168.2.
И все.. Система проста и понятна, но увы, это только показ. А мне нужна рулилка.
Если что, конфиг в /etc/websvn, поправить там скорее всего только 1 строчку надо:
$config->parentPath("/svn/repos");
это путь к репам. Все.
Чуть больше о настройке - http://debianworld.ru/articles/ustanovka-i-nastrojka-subversion-apache-websvn-v-debian-ubuntu-2/
понедельник, 1 ноября 2010 г.
Управление репами SVN
Заинтересовался интерфейсами для управления репозитариями SVN через web, нашел для себя 3:
USVN
SVNManager
Submin
Не нашел всех трёх ни во фре, ни в центоси. Благо, 2 из них на пхп, ставятся простым копированием. 3 на питоне, тут сложнее.
http://www.ossg.ru/wiki/Admin/Web-интерфейсы%20для%20Subversion
http://ru.wikipedia.org/wiki/SVN
Сделал поиск в центоси...
viewvc.noarch : Browser interface for CVS and SVN version control repositories
websvn.noarch : Online subversion repository browser
USVN
SVNManager
Submin
Не нашел всех трёх ни во фре, ни в центоси. Благо, 2 из них на пхп, ставятся простым копированием. 3 на питоне, тут сложнее.
http://www.ossg.ru/wiki/Admin/Web-интерфейсы%20для%20Subversion
http://ru.wikipedia.org/wiki/SVN
Сделал поиск в центоси...
viewvc.noarch : Browser interface for CVS and SVN version control repositories
websvn.noarch : Online subversion repository browser
Надо бы и их тоже глянуть.
Подписаться на:
Сообщения (Atom)