?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
blame, praise, svn
nyaload
_winnie
В command line клиенте svn есть команды blame (обругать) и praise (восхвалить), которые делают одно и то же.



  • 1
Оно слишком скучное, без эмоций :)

А что ты как батька питона не юзаешь меркуриал?

1) Потому что на работе используется svn, и учитывая количество клиентских билд-скриптов и серверных коммит-хуков это не изменится.

1б) Коллега рядом попробовал какие-то обёртки вокруг svn, вроде git2svn. По его словам, Git справляется с нашим количеством ресурсов, а Hg дохнет (полмиллиона файлов).

2) Для домашних целей одного человека svn хватает более чем достаточно.

а. ну 1 и 1б понятно, но вот для 2 я некоторое время назад переехал на hg. Куда более удобное.
Не говорю, что свн неудобный, просто по факту с hg комфорта больше, факт.

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

1б) дохнет и гит, и хг - особенно под виндами

Я для домашних перешёл с svn на hg - обратно не хочу.
Проще таскать репозитории и всегда можно поработать вне дома.

hg — тормозное говно, например. И у него staging нет.

Тормозное по сравнению с чем? По сравнению с svn - hg работает быстрее.
Возьмите к примеру получение логов.

C git, естественно. svn на логах тормозит исключительно потому, что ему надо по сети за ними ходить (а не локально, как hg), если рассматривать случай с локальным svn-сервером, то большой разницы не будет.

А так, когда я делаю checkout moin-овского репозитория после мержа, то можно спокойно идти пить чай, потому что 20 МИНУТ БЛЯДЬ ОНО ЕБЁТ ПРОЦЕССОР И СЕТЬ, хотя репозиторий там в разы меньше ядра, например (репозиторий которого, например, пуллится меньше минуты).

Про staging: с гитом огромной практики нет; есть много свн и полгода git - в чём именно профит стейджинга пока не понимаю :-)

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

Ну, это даже в обижаемом всеми svn можно.

cp file file.back
svn revert file
WinMergeUI file file.back # визуальный дифф с двумя панельками
#из WinMergeUI вставляю правки из file.back в file и коммичу по одному
rm file.back

Да-да, это в разы удобнее, чем git add --interactive.

В hg что-то такое было (какой-то из стандартных плагинов), но я вместо этого цинично юзаю (под виндой) tortoisehg - ввожу hgtk ci и получаю удобный гуёвый диалог для расстановки галочек на файлы и включения-исключения чанков, которые должны войти в коммит.

P.S. git не критикую - ибо до него просто руки не дошли...

Особенно в случае многих файлов и многих коммитов.

А нахер оно надо, кроме как для солопроектов?

Лично мне оно удобно.

blame вроде из гита приехал (annotate у него вообще нет).

А, не, таки есть. Но все используют blame.

"приехал из гита" это как?

Слышал легенду, что такое название для annotate придумал Линус во время написания собственно гита по понятным причинам. Хотя не исключаю варианта, что меня наебали.

Подозреваю, что в данном случае Линусу приписывают слишком много credit :) Из репозитория svn:

r847463 | mbk | 2003-10-12 20:35:51 +0400 (Вс, 12 окт 2003) | 23 lines

An initial implementation of "svn blame", which is meant to be somewhat
analogous to "cvs annotate".

r843048 | gstein | 2002-08-15 08:50:02 +0400 (Чт, 15 авг 2002) | 1 line

Add Daniel Berlin's draft of a 'blame' script.

Зато annotate полит корректно.

Всеже он обычно именно blame и не отругать а обвинить.

  • 1