Давно была идея визуализировать impact человека на продукт. Мощные визуализаторы типа codeswarm (активность и совместная работа) и gource (процесс работы) показывали не совсем то, что хотелось - текущее состояние. При помощи hg log -u username -p | grep "^+" | wc -l можно посчитать добавления и удаления, но опять же в динамике не увидеть. Хотелось увидеть как росла доля пришедшего человека, насколько быстро она затухала с уходом и какое наследие осталось.
Сначала я полез курить физические движки типа box2d, но какой-то он был скучный и неинтересный - хотелось получить результат за один день. Пришлось отказаться от физического моделирования и вывести данные для простой временноОй диаграммы с накоплением.
Полез курить Mercurial API, заодно накидал ссылок в вики-статью и скачал бесплатный PyCharm. На проект не тянет, поэтому сохранил в gist (derived work требует назначить лицензию GPL). Программа последовательно в каждой ревизии аннотирует текстовые файлы и считает, количество строк для каждого коммитера. Тестировал на маленьком репозитории, и не заметил нескольких улучшений. Пока работал на нашем основном - успел внести несколько правок.
5. Наконец включаем подсчет и запускаем
6. Ждем результат, открываем в Excel и рисуем график
Проанализировано 164.564.370 строк в 1135 коммитах (только ветка default) за 8 часов на Atom N550, потребление памяти в пике 75мб, диск был SSD, но IO был неизмеримо мал.
График очень резкий, поскольку разработка зачастую ведется в отдельных ветках, а мощный рефакторинг не сохранял исходного владльца файлов март 2012 (хехе, прямо война правок).
Сначала я полез курить физические движки типа box2d, но какой-то он был скучный и неинтересный - хотелось получить результат за один день. Пришлось отказаться от физического моделирования и вывести данные для простой временноОй диаграммы с накоплением.
Полез курить Mercurial API, заодно накидал ссылок в вики-статью и скачал бесплатный PyCharm. На проект не тянет, поэтому сохранил в gist (derived work требует назначить лицензию GPL). Программа последовательно в каждой ревизии аннотирует текстовые файлы и считает, количество строк для каждого коммитера. Тестировал на маленьком репозитории, и не заметил нескольких улучшений. Пока работал на нашем основном - успел внести несколько правок.
Процесс запуска
1. Запускаем первый раз python participation.py - у нас появится шаблон конфига
2. Отключаем подсчет calculate=false и прописываем репозиторий repo=~/path/to/repo
3. Запускам еще раз и получаем на выходе пользователей
4. Прописываем им алиасы в разделе [Alias] - часто один пользователь попадает под разными именами, а мы не хотим портить статистику5. Наконец включаем подсчет и запускаем
6. Ждем результат, открываем в Excel и рисуем график
Статистика
На серьезных репозиториях работает ОЧЕНЬ долго.Проанализировано 164.564.370 строк в 1135 коммитах (только ветка default) за 8 часов на Atom N550, потребление памяти в пике 75мб, диск был SSD, но IO был неизмеримо мал.
График очень резкий, поскольку разработка зачастую ведется в отдельных ветках, а мощный рефакторинг не сохранял исходного владльца файлов март 2012 (хехе, прямо война правок).
