Есть ли хороший SVN-инструмент для удобного просмотра прошлых ревизий?

Question

Контроль источника отличный. Одной из приятных особенностей является то, что я знаю, что могу вернуться к предыдущим ревизиям, если что-то не так.

Тем не менее, я все еще не хочу удалять большой пакет кода, который больше не нужен, но который я, возможно, захочу использовать в будущем. Это действительно не имеет никакого отношения к текущей базе кода. Однако я не люблю его удалять, потому что у меня нет простого способа просмотреть мою историю изменений и найти ее. Я буду часто вырезать и вставлять его и помещать в файлы с такими описательными именами, как «unused» и «tmp», и они будут сидеть там некоторое время.

Эта проблема была бы решена, если бы у меня был отличный способ просмотреть историю репозитория / поиск кода из прошлого. Есть ли графический интерфейс, который позволяет мне это делать, или какой-либо простой в использовании процесс, который я могу использовать? Есть ли способ сделать это с TortoiseSVN? Прямо сейчас единственный подход, который я знаю, чтобы выбрать, состоит в том, чтобы проверить различные номера ревизии, чтобы видеть, есть ли файл, который я хочу, там, и это просто слишком долго.

Answer 1

Что мне нравится делать, так это добавлять тег: скажем "Codebase_before_removing_such_and_such_function".Затем вы можете зайти в Браузер репозитория в TortoiseSVN, перейти к этому тегу и покопаться в нем, чтобы найти старый файл.Нажмите на этот файл и выберите «открыть», чтобы увидеть код в этом файле.

Вы также можете сделать то же самое, изменив браузер репозитория, чтобы он указывал на конкретную ревизию, а не указывал на HEAD (и, опять же, затем перейдите к нужному файлу и откройте его), но пометить его легче, потому что вы можете дать ему значимые имена.

Answer 2

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

Пример:

svn log -v --xml /path/to/repo | xml sel -T -t -m "//logentry/paths/path[@action='D']" -v "concat(../../@revision,': ',.)" -n

Пример вывода:

103: /foo/deprecated.h
99: /foo/bar/badfile.hpp

Очевидно, с помощью svn log вы можете ограничить это диапазоном ревизий (-r M: N), или диапазон дат (-r {date1}: {date2}), или последние N изменений (-l C).

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

Как только вы узнаете ревизию, в которой она была удалена, вы можете использовать svn cat или svn export , чтобы посмотреть наfile:

svn cat /path/to/repo/foo/deprecated.h@102

Так как deprecated.h был удален в r103, я сказал svn, чтобы получить путь к deprecated.h, как он существовал в r102 (до удаления).

Answer 3

Вы можете сделать это, просматривая изменения в SVN Tortoise ... однако ...

Я лично предпочитаю Mercurial .

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

Это немного отличается от черепахи (которую я использую на работе), но определенно лучшенасколько я понимаю.