Есть ли способ выполнить полнотекстовый поиск в репозитории Subversion, включая всю историю?
Например, я написал функцию, которую где-то использовал, но тогда в ней не было необходимости, поэтому я сделал svn rm файлы, но теперь мне нужно найти ее снова, чтобы использовать для чего-то другого. В журнале svn, вероятно, написано что-то вроде «удалил неиспользуемый материал», и есть множество подобных проверок.
Изменить 2016-04-15: Обратите внимание, что здесь под термином «полнотекстовый поиск» задается искать фактические различия в истории коммитов, а не имена файлов и / или сообщения фиксации. Я указываю на это, потому что формулировка автора выше не очень хорошо отражает это - поскольку в его примере он мог бы с таким же успехом искать только имя файла и / или сообщение фиксации. Отсюда и множество ответов и комментариев svn log.
svn log --search не выполняет полнотекстовый поиск, как того требует @rjmunro, а ищет только автора, дату, сообщение журнала и список измененных путей.





У меня нет опыта с этим, но SupoSE (открытый исходный код, написанный на Java) - это инструмент, предназначенный именно для этого.
Я давно искал нечто подобное. Лучшее, что я придумал, - это OpenGrok. Я еще не пробовал это реализовать, но звучит многообещающе.
Я использую OpenGrok несколько месяцев, он потрясающий.
Лучший способ добиться этого - с меньшими затратами:
svn log --verbose | less
Как только появится меньше результатов, вы можете нажать / для поиска, например, VIM.
Редактировать:
По словам автора, он хочет искать больше, чем просто сообщения и имена файлов. В этом случае вам нужно будет взломать его вместе с чем-то вроде:
svn diff -r0:HEAD | less
Вы также можете заменить grep или что-то еще, чтобы поискать за вас. Если вы хотите использовать это в подкаталоге репозитория, вам нужно будет использовать svn log, чтобы определить первую ревизию, в которой существовал этот каталог, и использовать эту ревизию вместо 0.
Это не полнотекстовый поиск, это поиск в журналах и именах файлов.
В этом случае вам нужно использовать более выразительные журналы фиксации. Если вы хотите увидеть разницу между ревизиями, это совсем другое дело. И я лично не знаю, как это сделать.
> svn diff -r0: HEAD> log> less log - мой выбор в Windows. Спасибо
Обычно я делаю то, что говорит Джек М (используйте svn log --verbose), но я использую grep вместо less.
Это не полнотекстовый поиск, это поиск в журналах и именах файлов.
Это то, что я обычно делаю, но я обнаружил, что с less вы действительно можете видеть версию, дату и т. д., А не только строку в комментарии. В любом случае это обычно то, что я ищу.
Я искал то же самое и нашел вот это:
Если вы используете Windows, посмотрите SvnQuery. Он поддерживает полнотекстовый индекс локальных или удаленных репозиториев. Каждый документ, когда-либо помещенный в репозиторий, индексируется. Вы можете выполнять запросы, похожие на Google, через простой веб-интерфейс.
Было бы здорово, если бы SvnQuery все еще поддерживался, но, к сожалению, он умер и теперь просто не работает.
Я нашел рабочий клон (?) В github.com/kalyptorisk/svnquery/releases
Я использую небольшой сценарий оболочки, но он работает только для одного файла. Вы, конечно, можете объединить это с find, чтобы включить больше файлов.
#!/bin/bash
for REV in `svn log | grep ^r[0-9] | awk '{print }'`; do
svn cat -r $REV | grep -q
if [ $? -eq 0 ]; then
echo "$REV"
fi
done
Если вы действительно хотите найти все, используйте команду svnadmin dump и выполните поиск с помощью grep.
Мне пришлось удалить «r» из номеров ревизий с помощью: awk '{print substr ($ 1,2, length ($ 1))}' и удалить опцию grep «-q», чтобы фактически отображать совпадения.
строки myDump.txt | grep "черепаха fwd 10"
Вот почему мы принимаем git.
может потребоваться выполнить последний grep -i для игнорирования регистра и отбросить -q, чтобы фактически увидеть строку, которая соответствует
Хотя это не бесплатно, вы можете взглянуть на Fisheye от Atlassian, тех же людей, которые предлагают вам JIRA. Он выполняет полнотекстовый поиск по SVN со многими другими полезными функциями.
http://www.atlassian.com/software/fisheye/
Рыбий глаз довольно хорош. Как вы говорите, не бесплатно, но лицензия коммиттера <= 10 стоит всего 10 долларов в год.
В настоящее время 5 пользователей стоят 10 долларов, НО только для 10 пользователей он подскакивает до 1000 долларов!
Я просто столкнулся с этой проблемой и
svnadmin dump <repo location> |grep -i <search term>
сделал всю работу за меня. Вернул ревизию первого появления и процитировал строку, которую искал.
Работает только локально и займет много времени, если репозиторий большой.
git svn clone <svn url>
git log -G<some regex>
Хорошая точка зрения. Графический интерфейс gitk очень хорошо выполняет такой поиск, и для доступа к репозиторию svn легко использовать инструменты git svn. К слову, с тех пор, как я задал этот вопрос, я полностью перешел на использование git, поэтому принятие этого ответа может быть для меня немного специфичным.
Если вы хотите просто искать сообщения фиксации, используйте git log --grep regex.
Имейте в виду, что это может занять некоторое время в зависимости от размера вашего репозитория. У меня на это ушло больше часа.
Неужели это перебирает всю историю?
@rjmunro: простой git grep < some regex >, как указано в ответе, вообще не выполняет поиск в истории. Таким образом, это вообще не отвечает на ваш вопрос.
@ zb226 Преобразование в git и поиск с помощью gitk gui у меня сработали. Я предположил, что этот ответ был эквивалентным способом сделать это из командной строки. На самом деле похоже, что эквивалентная команда - git log -S (из этот ответ), но git log -G может быть даже лучше. Редактирую этот ответ.
Я отклонил это решение, поскольку преобразование большого репозитория SVN в GIT часто невозможно или займет слишком много времени. Это все равно, что рекомендовать Java, когда возникает вопрос о конструкции языка C#.
Возможно, вам потребуется установить дополнительный пакет для этой команды. В Ubuntu вам нужен apt-get install git-svn.
Разве "svn log --verbose --diff | grep ..." не покупает вам примерно такую же функциональность без использования git?
@lyte Это примерно тот же функционал. Это очень хорошо, если вы работаете только с svn. Мне кажется смешной идея использовать git для поиска коммитов. Проблема начинается, когда вы хотите увидеть больше, чем просто строку, содержащую искомый термин. grep может напечатать несколько строк до и после обнаружения, но вы никогда не знаете, сколько строк вам нужно (чтобы найти номер версии вверху или весь комментарий внизу). Вывод трудно читать.
Это поиск с помощью git, а не поиск с помощью SVN в соответствии с вопросом. Это эквивалентно предоставлению скрипта Python для ответа на вопрос C - он работает, но не отвечает на исходный вопрос.
Я написал это как сценарий cygwin bash для решения этой проблемы.
Однако для этого требуется, чтобы поисковый запрос в настоящее время находился в файле файловой системы. Для всех файлов, которые соответствуют grep файловой системы, затем выполняется grep для всех svn diff для этого файла. Не идеально, но должно быть достаточно для большинства случаев использования. Надеюсь это поможет.
/ USR / местные / бен / svngrep
#!/bin/bash
# Usage: svngrep $regex @grep_args
regex = "$@"
pattern=`echo $regex | perl -p -e 's/--?\S+//g; s/^\s+//;'` # strip --args
if [[ ! $regex ]]; then
echo "Usage: svngrep $regex @grep_args"
else
for file in `grep -irl --no-messages --exclude=\*.tmp --exclude=\.svn $regex ./`; do
revs = "`svnrevisions $file`";
for rev in $revs; do
diff=`svn diff $file -r$[rev-1]:$rev \
--diff-cmd /usr/bin/diff -x "-Ew -U5 --strip-trailing-cr" 2> /dev/null`
context=`echo "$diff" \
| grep -i --color=none -U5 "^\(+\|-\).*$pattern" \
| grep -i --color=always -U5 $pattern \
| grep -v '^+++\|^---\|^===\|^Index: ' \
`
if [[ $context ]]; then
info=`echo "$diff" | grep '^+++\|^---'`
log=`svn log $file -r$rev`
#author=`svn info -r$rev | awk '/Last Changed Author:/ { print }'`;
echo "======================================================================= = "
echo "======================================================================= = "
echo "$log"
echo "$info"
echo "$context"
echo
fi;
done;
done;
fi
/ USR / местные / бен / svnrevisions
#!/bin/sh
# Usage: svnrevisions $file
# Output: list of fully numeric svn revisions (without the r), one per line
file = "$@"
svn log "$file" 2> /dev/null | awk '/^r[[:digit:]]+ \|/ { sub(/^r/,"",); print }'
«А» за усилия! (просто используйте git :))
Наткнулся на этот bash скрипт, но не пробовал.
svn log в Apache Subversion 1.8 поддерживает новый вариант --search. Таким образом, вы можете искать сообщения журнала истории репозитория Subversion без использования сторонних инструментов и скриптов.
svn log --search ищет автора, дату, текст сообщения журнала и список измененных путей.
См. SVNBook | Справочник по командной строке svn log.
Удобный, но не полнотекстовый поиск. Я придерживаюсь ответа git-svn :-)
Не то чтобы на данный момент репозитории svn на googlecode все еще работают на svn 1.6 ... см .: code.google.com/p/support/wiki/…? Но обновление вашего клиента до 1,8 (и обновление svn любого проверенного репо) позволит вам использовать svn log --search в репо ...
Рабочей копии требуются все обновления, но эта команда отображает все изменения, включая номер редакции, измененные файлы и комментарий. Как это не полнотекстовый?
svn log -v [repository] > somefile.log
для diff вы можете использовать опцию --diff
svn log -v --diff [repository] > somefile.log
затем используйте vim или nano или что угодно, что вам нравится, и выполните поиск того, что вы ищете. Вы найдете это довольно быстро.
Это не причудливый сценарий или что-то автоматизированное. Но это работает.
AFAICS, это будет искать сообщения фиксации, а не фактические различия.
Затем используйте svn log -v --diff [репозиторий]> somefile.log
или просто пропустите grep, как в ответе zednight
svn log -l<commit limit> | grep -C<5 or more lines> <search message>
добавьте --diff к этому, чтобы получить текстовый поиск изменений
Если вы пытаетесь определить, какая ревизия отвечает за конкретную строку кода, вы, вероятно, ищете:
svn blame
Кредит: оригинальный ответ
Apache Subversion 1.8 принимает аргумент
--searchдля командыsvn log. Смотрите мой ответ на stackoverflow.com/a/17473516/761095