?

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 не критикую - ибо до него просто руки не дошли...

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

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

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

  • 1