Является ли выполнение "svn log -q -v" во всех ревизиях для корня хранилища с последующей фильтрацией по нужному пути действительно лучшим (только?) Способом сделать это? Нам необходимо найти эти диапазоны, чтобы обеспечить автоматическую проверку версий и добавить вспомогательные сведения в нашу отчетность об изменениях.
Я сделал небольшую оптимизацию, чтобы запросить рут уже:
Задан путь:
Протокол: //server/repo/a/b/c/d/foo.txt
Я уже написал скрипт для выполнения повторяющихся запросов журнала svn по пути:
svn log -q -v ... / a / b / c / d / foo.txt
svn log -q -v ... / a / b / c / d
svn log -q -v ... / a / b / c
svn log -q -v ... / a / b
svn log -q -v ... / a
svn log -q -v ...
пока я не получу:
svn: файл не найден: ...
Я не проводил значительных тестов профилирования, но мне кажется, что ошибки должны обрабатываться достаточно быстро, и общее потенциальное сокращение сетевого трафика должно перевешивать стоимость повторных запросов во всех случаях, кроме одного, в котором хранилище Корень должен быть запрошен в любом случае.
Вышеприведенное не работает, если у предка несколько живых диапазонов; если кто-то не знает лучше, мой единственный вариант - запросить из корня хранилища.
Из результатов я, по сути, хочу список отдельных диапазонов, в которых существует файл (который я позже могу изменить, чтобы также отслеживать историю, чтобы у воскрешенного файла было несколько диапазонов; как бы странно это ни звучало, у нас есть случаи где файлы с одинаковым путем оказываются не связанными). В данный момент я анализирую номера ревизий по мере их прохождения, отслеживая последнюю ревизию нужного пути, где он или один из его предков был удален (изначально HEAD, который будет перезаписан, если я увижу удаление). Когда я вижу, что путь был добавлен, я выбрасываю диапазон rev_added - rev_lastdeleted.
Вышеописанное работает, но оно включает в себя прохождение довольно большого количества информации, большая часть которой ложная. Есть ли более эффективный способ сделать это, предпочтительно тот, в котором больше работы выполняется на стороне сервера, чтобы минимизировать сетевой трафик (большая часть нашей работы выполняется удаленно через VPN)?
Похоже, что TortoiseSVN может предоставить эту же информацию единственным способом - выполнить тот же процесс (получить журнал предка и затем выполнить фильтрацию).