Есть ли хороший инструмент SVN, чтобы легко просматривать предыдущие версии?

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

Вы можете использовать командную строку svn с -v (verbose, показывая измененные пути) и --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 можно ограничить, что в диапазоне ревизий (-r M: N), или диапазон даты (-r {date1}: {date2}) или последние N ревизий (-l C).

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

После того, как вы знаете, в какой ревизии был удален, вы можете использовать Svn кошку или экспорт Svn посмотреть на файл:

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

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