FreeBSD. Переезжаем с Subversion на Mercurial +Trac
На днях все-таки переехали с vasa_c'ом на Mercurial. Возникли трудности с перемещением ревизий из Subversion в Mercurial, а также с настройкой Trac.
Работать будем от имени и группы - www.
Путь до файлов с данными svn - "/var/svn", до hg - "/var/hg", для trac - "/var/trac".
Имя проекта для примера - "EXAMPLE".
Запускать hg serve будем на порту 8010.
Установка и настройка Mercurial
Установим сам Mercurial:
cd /usr/ports/devel/mercurial
make install clean
Создаем каталог для хранения данных Mercurial и репозиториев:
[web]
# стиль gitweb
style = gitweb
# при пушенге не использовать SSL
push_ssl = false
# разрешить всем пушинг, по поводу авторизации см. ниже
allow_push = *
Добавим свое имя для hg и авторизационные данные, отредактируя hgrc:
emacs /home/USER1/.hgrc
Вы так же можете прописать настройки персонально для проекта, например в "/home/USER1/projects/EXAMPLE/.hg/hgrc", где "/home/USER1/projects/EXAMPLE" - ваша рабочая копия проекта EXAMPLE.
И приводим соответствующие секции и переменные к такому виду:
[trac]
repository_type = hg
repository_dir = /var/hg/repos/EXAMPLE
[components]
tracext.hg.* = enabled
[hg]
# -- Show revision number in addition to the changeset hash
show_rev = yes
# -- Changeset hash format
node_format = short
# hex: Show the full SHA1 hash
# short: Show a shortened hash for the changesets
После установки плагина и настройки проекта не забудьте перезагрузить Tracd или другой веб-сервер, через который вы работаете с Trac.
Теперь, если у вас в Timeline появились символы вопросов вместо кириллических комментариев к ревизиям, вам необходимо установить HGENCODING="utf-8":
Более подробно изучить проблему с битыми символами при выводе сообщения к ченжлогу, вы можете посмотрев исходный код Mercurial, а именно в файле "/usr/local/lib/python2.6/site-packages/mercurial/encoding.py" функция "tolocal".
Да ну нафиг, юзал я редмайн... мне совершенно не понравился, Trac его всетаки лучше будет, имхо. Если что-то лучше Trac'а, то это какой-нибудь TargetProcess или Jira. Да и вообще речь о Mercurial была, трак упоминается в статье только из-за того что мы его используем и дополнительно о нем написал.
P.S. я ставил редмайн без каких-либо плагинов, возможно они бы и исправили мое мнение
кроме hgsvn еще есть
- yahg2svn (http://hg.rosdahl.net/yasvn2hg)
- http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension
- Tailor (http://progetti.arstecnica.it/tailor)
http://adw0rd.ru/files/hg.txt
--webdir-conf заменить на --web-conf
еще hg.txt сам надо конвертнуть из ansi в utf-8
и неплохо бы добавить --errorlog /var/log/hgserve.log
предварительно создав этот файл
httpd-error.log не содержит ошибок (не сомтря на DEBUG логирование apache)
вместо hg теперь git пользуете? чем hg не устроил? вроде удобное и мощное средство
например под виндами локальное хранилище пока пользую и очень удобно у tortoise возможность запуска из меню сервера
запустил сервер, все из команды подконнектились в мою локальную ветку засинхронились и дальше пошли работать
а я уж потом на сервер все залить могу или кто другой из команды сам сделает
плюс разные бонусы ппри слиянии и разных ответвлений ...
Потомучто git это все умеет и ещё сверху куча возможностей (stash, submodules, bisect и т.п.). Поведение консольных утилит у него удобнее и облегчает работу (log с пагинатором; grep ищет только по коду; подсветка сделана правильно, а не так костыльно как в hg), вообщем когда начинаешь работать с git, то там и остаешься.
Вот из моего черновика кое что:
В отличии, например, от того же Mercurial (с моделью "Work-tree"->"Repository") Git имеет модель "Work-tree"->"Index"->"Repository" - которая позволяет последовательно подготавливать изменения для коммита, выборочно применять изменения и визуально отделять "зерна от плевел" в git-status;
Нету анонимных веток (heads, голов), от которых я в свое время уставал;
Auto-merge - это мега-полезная фича для ленивых программистов, однако рекомендую всетаки их подписывать через "git-commit --amend";
На мой взгляд гораздо проще чем Mercurial, в том плане что команды кажутся более интуитивными и удобными (например "git-add -p" - который ханк-за-ханком позволяем применять изменения или "git-pull" - который не просто фетчит, но и мержит);
git лучше поддается кастомизации, можно делать свои алиасы очень гибкими;
ну в догонку для холивара более детальное сравнение
я очень много сторон пересмотрел перед тем как выбрать систему
теперь бы trac заставить работать на ртути и было бы круто у меня все
а как насчет такого контраргумента в пользу ртути (?) http://habrahabr.ru/post/123700/
да, читал об этом, в том же моем черновике написано что на практике я этой проблемы не разу не ощутил, хоть мы и активно использовали ветки (все время было порядка 50-300 веток) в одном из проектов
ну в догонку для холивара более детальное сравнение я очень много сторон пересмотрел перед тем как выбрать систему теперь бы trac заставить работать на ртути и было бы круто у меня все
ну Trac тоже очень примитивный (я от него отказался), я предпочитаю продукты от Atlassian: Jira+GreenHopper+(FishEye,Git-plugin,Stash), в добавок ещё Crucible... и можно пользоваться Bamboo, но сейчас использую Jenkins (потому что плагинов и комьюнити больше на мой взгляд)
Комментарии
Редмайн как-то покруче выглядит
Да ну нафиг, юзал я редмайн... мне совершенно не понравился, Trac его всетаки лучше будет, имхо. Если что-то лучше Trac'а, то это какой-нибудь TargetProcess или Jira. Да и вообще речь о Mercurial была, трак упоминается в статье только из-за того что мы его используем и дополнительно о нем написал.
P.S. я ставил редмайн без каких-либо плагинов, возможно они бы и исправили мое мнение
Мийка, ты когда разбанишься на пыхе?
Имя, мы знакомы? :)
Ну мне еще нужен отдых, еще месяцок наверное... Надо много проектов подтянуть и т.д.
и в чем прелесть этого трака американского ?)
Спасибо, статья пригодилась
Мне интересно почему вы выбрали именно меркуриал? Почему не gti? Или еще что нибудь поуникальнее? )
Потомучто меркуриал проще для нас оказался чем гит, при переходе с свн
В каком плане проще? Проще в миграции с свн или в работе?
В плане работы. Возможно в скоре будет переход на гит, так как с недавнего времени я стал активно его использовать на работе
так не заработало с нджинксом.
заработало так:
Спасибо, видимо скопипастил из своей другой статьи про свн :)
py-htpasswd меня устраивает, апатч зло
ln -s /usr/local/bin/htpasswd.py /usr/local/bin/htpasswd
кроме hgsvn еще есть
- yahg2svn (http://hg.rosdahl.net/yasvn2hg)
- http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension
- Tailor (http://progetti.arstecnica.it/tailor)
+1, там где нет apache2-utils (например FreeBSD), я тоже пользуюсь htpasswd.py
correct installation mercurial plugin for trac (actual ver 1.0.0.1)
hg clone https://hg.edgewall.org/trac/mercurial-plugin
python setup.py bdist_egg
python setup.py install
http://adw0rd.ru/files/hg.txt
--webdir-conf заменить на --web-conf
еще hg.txt сам надо конвертнуть из ansi в utf-8
и неплохо бы добавить --errorlog /var/log/hgserve.log
предварительно создав этот файл
trac не работает по окончании
500 код ошибки сервер возвращает
Видимо в новых версия теперь так... Я не в курсе этого, так как перестал пользоваться hg
Зачем?
раньше работал, значит что-то поменялось, посмотрите nginx-error.log
httpd-error.log не содержит ошибок (не сомтря на DEBUG логирование apache)
вместо hg теперь git пользуете? чем hg не устроил? вроде удобное и мощное средство
например под виндами локальное хранилище пока пользую и очень удобно у tortoise возможность запуска из меню сервера
запустил сервер, все из команды подконнектились в мою локальную ветку засинхронились и дальше пошли работать
а я уж потом на сервер все залить могу или кто другой из команды сам сделает
плюс разные бонусы ппри слиянии и разных ответвлений ...
так почему от hg отказались?
Потомучто git это все умеет и ещё сверху куча возможностей (stash, submodules, bisect и т.п.). Поведение консольных утилит у него удобнее и облегчает работу (log с пагинатором; grep ищет только по коду; подсветка сделана правильно, а не так костыльно как в hg), вообщем когда начинаешь работать с git, то там и остаешься.
Вот из моего черновика кое что:
http://habrahabr.ru/post/104198/
http://git-scm.com/about
а как насчет такого контраргумента в пользу ртути (?)
http://habrahabr.ru/post/123700/
ну в догонку для холивара более детальное сравнение
я очень много сторон пересмотрел перед тем как выбрать систему
теперь бы trac заставить работать на ртути и было бы круто у меня все
да, читал об этом, в том же моем черновике написано что на практике я этой проблемы не разу не ощутил, хоть мы и активно использовали ветки (все время было порядка 50-300 веток) в одном из проектов
ну Trac тоже очень примитивный (я от него отказался), я предпочитаю продукты от Atlassian: Jira+GreenHopper+(FishEye,Git-plugin,Stash), в добавок ещё Crucible... и можно пользоваться Bamboo, но сейчас использую Jenkins (потому что плагинов и комьюнити больше на мой взгляд)
Оставьте свой комментарий