Журнал SVN фиксированного пути между копиями и перемещениями

Question

Я пытаюсь получить историю журнала (рекурсивно, если возможно) фиксированного пути в SVN для всех копий / перемещений / и т. Д. По сути, я пытаюсь избежать ревизий колышков и заставить журнал применяться к пути, а не к объектам. Руководство SVN ставит этот вопрос - «Вы спрашиваете об операциях, которые произошли со всеми объектами, которые когда-либо жили на этом пути?» - но, по-видимому, он не предоставляет возможности для этого варианта использования. Предполагается, что это не то, что вы хотите, но это именно то, что я хочу.

Есть ли способ сделать это без выдачи повторяющихся запросов, чтобы преодолеть разрыв между разными копиями, живущими по фиксированному пути в истории изменений SVN?

Answer 1

Я не знаю ни одного способа в SVN.Вся история кажется с точки зрения объекта, а не с точки зрения хранилища.Даже сделать это, соединив несколько запросов, было бы непросто, потому что вы должны выяснить, когда объект перемещен, и вы должны сделать новый запрос.

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

Answer 2

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

http://subversion.tigris.org/issues/show_bug.cgi?id=928

Надеюсь, это будет возможно в будущем выпуске.

Answer 3

Используйте ViewVC с функцией «фиксации базы данных».Он извлечет метаданные о каждом коммите в базу данных SQL.Затем вы можете запросить в базе данных SQL все коммиты, которые повлияли на конкретный путь.

Первоначальное извлечение метаданных занимает длительное время - около 12 часов для репозитория 10 ГБ - но это нужно сделать только один раз.Затем вы можете настроить хук после фиксации для обновления метаданных при каждом коммите, что быстро.База данных метаданных среднего размера - около 200 МБ для хранилища объемом 10 ГБ.

Запрос метаданных выполняется быстро.

Answer 4

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