Получить пакетную информацию журнала SVN наиболее эффективно

Question

Я ищу способ оценить, какой разработчик внес наибольший код для каждого файла в репозитории SVN. Единственный способ, который я мог бы выяснить, это получить журнал svn для каждого файла, проанализировать первую строку и написать все эти записи. Проблема в том, что выборка полного журнала отдельно для каждого файла очень неэффективна и занимает много времени.

1. Есть ли способ получить все записи журнала для папки, но также и с именем файла? По умолчанию svn-операция, похоже, не указывает, какая запись журнала принадлежит к файлу, если вы запрашиваете журнал папок.
2. В качестве альтернативы, есть ли способ выполнить этот тип пакетных запросов в репозитории?

Ответы на использование команд командной строки svn или привязок языка программирования приветствуются.

Answer 1

Если вы хотите узнать, какой пользователь изменил, какие файлы на ревизию (не заботясь о количестве изменений), вы можете использовать опцию командной строки -v с svn log. Это также работает в полном рабочем каталоге, а также в удаленном репозитории.

Возможно, вы также захотите использовать опцию командной строки --xml. Это упрощает парсинг для большинства сред программирования.

Answer 2

Вы можете попробовать обратный подход: svn log --xml -v Прогон в корневом хранилище будет выводить полный журнал в формате XML, включая пути изменения. Затем вы разбираете его и собираете статистику.

Answer 3

О, мальчик, это будет интересная статистика.

Если вы оцениваете своих разработчиков с помощью этого метода, вы будете поощрять разработчиков заставлять много изменений и кода. Будет ли это использоваться для бонусов? Король-оркер Дилберта Уолли хотел бы этого. Он напишет себе Ferrari на 4 вечера. Однако, если вы настаиваете ...

Вместо анализа каждого файла вы можете просто взять журнал из корня интересующего вас проекта и передать диапазон исправлений, которые вы хотите.

Это даст вам имена разработчиков, которые совершили каждую ревизию. Вот пример:

$ svn log -r1:HEAD http://server/svn/project 
------------------------------------------------------------------------ 
r1 | david | 2011-07-12 15:18:33 -0400 (Tue, 12 Jul 2011) | 1 line 

Adding directories 
------------------------------------------------------------------------ 
r2 | bob | 2011-07-12 15:19:20 -0400 (Tue, 12 Jul 2011) | 1 line 

Adding property 
------------------------------------------------------------------------ 
r3 | mark | 2011-08-21 10:33:51 -0400 (Sun, 21 Aug 2011) | 1 line 

Если вы хотите, имена файлов тоже можно использовать --verbose параметр:

$ svn log -r1:HEAD --verbose http://server/svn/project 
------------------------------------------------------------------------ 
r1 | david | 2011-07-12 15:18:33 -0400 (Tue, 12 Jul 2011) | 1 line 
Changed paths: 
    A /branches 
    A /tags 
    A /trunk 

Adding directories 
------------------------------------------------------------------------ 
r2 | bob | 2011-07-12 15:19:20 -0400 (Tue, 12 Jul 2011) | 1 line 
Changed paths: 
    M /trunk 

Adding property 
------------------------------------------------------------------------ 
r3 | mark | 2011-08-21 10:33:51 -0400 (Sun, 21 Aug 2011) | 1 line 
Changed paths: 
    A /trunk/subversion 
    A /trunk/subversion/control.ini 
    A /trunk/subversion/pre-commit-kitchen-sink-hook.html 
    A /trunk/subversion/pre-commit-kitchen-sink-hook.pl 
    A /trunk/subversion/svn-watch.html 
    A /trunk/subversion/svn-watch.pl 

Adding files 
------------------------------------------------------------------------ 

---

Однако, если вы действительно хотят знать которые являются наиболее производительными программистами, не смотрите на код. Производительные разработчики пишут меньше кода, чем их более неэффективные коллеги. Хороший разработчик будет эффективно управлять потоком кода, поэтому есть несколько исключений для просмотра, в то время как слабый разработчик может принять неверный ключ, а затем должен обрабатывать все исключения из своих основных правил.

Эффективный разработчик исправляет тот файл, который содержит ошибку, а не меняет десятки файлов, пытаясь отследить ошибку. На самом деле, действительно хороший разработчик может даже признать, что проблему можно решить, изменив настройку среды, а не код.

Вы хотите выяснить, кто натягивает свой вес на арене разработки, посмотрите на свою систему отслеживания проблем. Кто работает над самыми большими проблемами и быстро их обходит? Кто добавляет функцию, не вызывая каскада ошибок?

Задача программистов - решить проблемы, а не код стропы.