Анонсирован (http://lists.sfconservancy.org/pipermail/kallithea-general/2...) первый выпуск системы управления репозиториями Kallithea (https://kallithea-scm.org/), основанной (http://www.opennet.me/opennews/art.shtml?num=40141) энтузиастами и представителями организации Software Freedom Conservancy с целью продолжения развития свободной кодовой базы RhodeCode, после превращения (http://www.opennet.me/opennews/art.shtml?num=37626) данной платформы в полупроприетарный коммерческий продукт. Kallithea позволяет развернуть инфраструктуру управления разработкой, которая поддерживает системы контроля версий Git и Mercurial, и по решаемым задачам напоминает GitHub и Bitbucket. Код проекта распространяется (https://kallithea-scm.org/repos/kallithea/) под лицензией GPLv3. Код проекта написан на языке Python.
Kallithea включает в себя высокопроизводительный сервер обработки push/pull-запросов и веб-интерфейс для организации совместной разработки, который позволяет управлять репозиториями, разделять права доступа, рецензировать код, отслеживать активность других участников, делать форки проектов, отправлять пулл-реквесты или изменять код на месте, через простой редактор. Поддерживается интеграция с централизованной базой пользователей предприятия, основанной на LDAP или ActiveDirectory. Поддерживается создание групп репозиториев и групп разработчиков с унификацией управления членами группы. Внешний вид интерфейса может легко быть изменён через систему шаблонов. Поддерживается наглядное представление активности в виде графиков. В системе рецензирования изменений поддерживается обсуждение изменений и отправка уведомлений.Серверная часть платформы является многопоточной, что позволяет одновременно обслуживать несколько pull/push-запросов. Для увеличения производительности в системе активно используется кэширование и выполнение действий в асинхронном режиме. В систему также интегрированы средства резервного копирования, позволяющие периодически архивировать и сохранять через scp копию всех данных. Для отслеживания активности в репозиториях поддерживается специальная прослойка, ведущая журнал всех обращений и позволяющая аутентифицировать каждый запрос. Для работы с репозиториями задействована библиотека vcs (http://pypi.python.org/pypi/vcs), мета-данные о проектах могут хранится в БД на основе SQLite, PostgreSQL или других, поддерживаемых SQLAlchemy.
Выпуск Kallithea 0.1 оценивается как стабильный и пригодный для введения в эксплуатацию. Особенности Kallithea 0.1:
- Поддержка новых выпусков dulwich, doctuils, pycrypto, mako, whoosh, babel, formencode, bcrypt и Mercurial 3.1.x;
- Поддержка удаления групп репозиториев;
- Возможность интеграции с внешними системами web-аналитики, такими как Google Analytics;
- Увеличена производительность при работе с большими репозиториями;
- Повышена информативность текстов ошибок, обеспечен вывод причины возникновения ошибок;
- Ссылки для меток в ветках теперь указывают на список изменений, а не на файлы;
- Проведена чистка JavaScript-кода, многие участки кода переведены с YUI на jQuery;
- Переработано оформление графиков;
- Улучшен интерфейс для формирования сообщений о проблемах. Возможность редактирования описания и заголовка сообщения о проблеме. Отображение активности в ветке после заведения PR. Поддержка добавления комментариев к закрытым PR;
- Улучшены интерфейсы для оценки различий и добавления комментариев.
- Обеспечено сохранение текущей ревизии при навигации между списками изменений и просмотром файлов;
- Поддержка указания имени ветки в URL со ссылкой на набор изменений (ветка отделяется при помощи символа '/');
- Обеспечен показ изображений в интерфейсах просмотра файлов и оценки изменений (diff).
URL: http://lists.sfconservancy.org/pipermail/kallithea-general/2...
Новость: http://www.opennet.me/opennews/art.shtml?num=40440
Высокопроизводительный сервер на питоне... я крайне хочу услышать мнение знающих людей на этот счет
А ты чего хотел, на асме писанный чтоли? В подавляющем большинстве случаев узкое место это база данных (как и любой I/O), а учитывая высокую скорость разработки на удаве, он становится весьма неплохим решением.
это не highload, сильнаям многопоточность не нужна.
ботлнек как писали выше будет db, другие ботлнеки можно переписать на Си.
Питон годный продукт, тем более есть pypy, потери в производительности должно быть не значительные для данного кейса.
> Высокопроизводительный сервер на питоне... я крайне хочу услышать мнение знающих людей
> на этот счет10 тыс запросов в секунду на сервер - это много, или мало?
>> Высокопроизводительный сервер на питоне... я крайне хочу услышать мнение знающих людей
>> на этот счет
> 10 тыс запросов в секунду на сервер - это много, или мало?10 тыс запросов в секунду и C10k problem это разные вещи.
и 10к запросов делающие что? на каком оборудование?то что на яве или хотя бы go это будет дешевле - это очевидный факт, питоновские проекты надо маштобироавть на большее кол-ва железа при равносильных нагрузках, чем если использовать яву.
> 10 тыс запросов в секунду и C10k problem это разные вещи.Я про 10k rps при обработке http запросов.
Простенькая логика, api всякие и т.д.> то что на яве или хотя бы go это будет дешевле -
> это очевидный фактНе факт, нужно ещё учитывать стоимость разработки.
ЗП разработчиков, стоимость поддержки и т.д.
наконец-то... хотя ченчлог невпечатлительный :( хотя бы множество ошибок исправлено. и хоть какая-то гибкость проявлена, а то rh приходилось гвоздями прибивать.
ну, по крайней мере через virtualenv в openbsd snapshots нормально установилась и заработала... :)
Функционал для code review есть?
понятия не имею.пока различий с rh 1.7, кроме зелёно-болотно-опеннетной темы, не увидел.
> пока различий с rh 1.7, кроме зелёно-болотно-опеннетной темы, не увидел.Признайся, это ведь тебе слава Дениса покоя не давала? :)
Сам жду этой штуки. То, что есть сейчас - тихий ужас.
Gitlab же