TFS vs Git vs Mercurial vs SVN vs ... , что лучше?

Цитата applegame @ 08.07.15, 06:28

Не все.

Велик и могуч русский язык - иногда в нём "все" означает "большинство"

Цитата negram @ 08.07.15, 08:02

- медленный. очень. очень-очень прям -- даже на сравнительно небольших репозиториях как и всё, что на питоне

Не знаю. В целом скорость устраивает. Вероятно, потому, что я исключительно через гуй работаю. Так что ок, запишем в плюс гиту.

Цитата negram @ 08.07.15, 08:02

- удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую.

Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно.

Цитата negram @ 08.07.15, 08:02

- git add -p ужасно не хватает.

А что это? Беглый гуглинг не помог.

Цитата negram @ 08.07.15, 08:02

и вообще разделения за committed/staged/unstaged.

А под этим что понимается? Ручное задание этих пометок файлам что ли?

Цитата negram @ 08.07.15, 08:02

hg record -- урезанный
-- конкретно урезанно:
-- нельзя перейти в режим редактирования патча
-- нельзя разбить патч на более мелкие части
-- нельзя временно пропустить патч, чтоб посмотреть что ещё в этом файле изменилось, чтоб принять решение по данному чанку

В консоли - может быть. В TortoiseHG при коммите разве что сами патчи нельзя редактировать. Но коммитить только часть патча и смотреть всё, что поменялось в файле вполне можно.

Цитата negram @ 08.07.15, 08:02

- git stash порой тоже не хватает. приходится делать hg diff > patch && some shit && patch -p1 < patch

Есть же shelve. В гуе это так вообще мегаудобно делается.

Цитата negram @ 08.07.15, 08:02

- откатить можно только последний коммит

Ты про hg rollback? Имхо, нафиг не надо - проще просто обновиться к нужной ревизии, а все ошибочные коммиты удалить или пометить секретными.

Цитата applegame @ 08.07.15, 09:07

а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/

Или постоянные "шозанах", стандартное объяснение которых сводится к "это не баг - это фича". Например, вот. Ну и на том же хабре в статьях-комментах периодически проскакивают советы "как надо делать нечто, чтобы не сломать репозиторий". Для hg таких советов я не припомню, да и вообще слабо представляю, как его можно сломать случайно.

Цитата

Total Physical Source Lines of Code (SLOC) = 310,135

Это - маленький. Едва приближается к среднему.

M

Поменял название темы

Цитата Бобёр @ 08.07.15, 10:49

Это - маленький. Едва приближается к среднему.

Дык, речь шла о "сравнительно небольших". Ну посмотрим через годик будут ли заметны тормоза.

Чем мне нравится в hg, так это то, что его завел и работаешь над проектом без головной боли, а в git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.
Нет у меня желания углубляться в тонкости "как оно работает". git меня заставляет углубляться, hg нет. А так в целом git - няшка, особенно github.

Сообщение отредактировано: applegame - 08.07.15, 11:42

Цитата applegame @ 08.07.15, 08:19

negram, это вот устарело?
http://habrahabr.ru/post/123700/

Мм. Вероятно, не устарело, но я так и не понял проблемы Вроде, через gitk очень даже показывается что надо

Цитата applegame @ 08.07.15, 09:07

negram, а как насчет черезжопной уродской системы команд git?

Всё ж не стоит использовать худ.литературу как мануал
Пока я вижу, что hg достаточно далёк от функционала git-а. Причём, это касается именно повседневной работы, уже не говоря о таких извращениях как например rerere

Цитата DarkEld3r @ 08.07.15, 09:11

Что именно надо делать, чтобы медленность "ощутить"?

push? Хотя, у меня чаще тормозит pull (обе эти команды занимают 5-20 секунд). На той неделе много раз пришлось клонировать репу, так это занимало по нескольку минут. А репозиторий-то -- всего 500K строк в сумме.

Добавлено 09.07.15, 07:35

Цитата OpenGL @ 08.07.15, 10:43

Цитата negram @ 08.07.15, 08:02

- удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую.

Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно.

Мне вот как-раз такое и надо было: есть несколько проектов, с одной кодовой базой, но иногда разными плюшками и разной релизовой жизнью. Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\

Сообщение отредактировано: negram - 09.07.15, 07:35

Цитата negram @ 09.07.15, 07:31

Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\

Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать.

Цитата OpenGL @ 08.07.15, 10:43

Цитата negram @ 08.07.15, 08:02

- git add -p ужасно не хватает.

А что это? Беглый гуглинг не помог.

Цитата negram @ 08.07.15, 08:02

и вообще разделения за committed/staged/unstaged.

А под этим что понимается? Ручное задание этих пометок файлам что ли?

Ответ сразу на оба вопроса картинкой, ибо расписывать долго. В кратце: изменения в коммит можно набирать в несколько этапов. Причём не файлами, а отдельными патчами. Алсо помогает при мерже, если произошли конфликты: всё, что нормально смержилось сразу добавляется в коммит (staged), остальное предлагается поправить и добавить.

Добавлено 09.07.15, 07:57

Цитата OpenGL @ 08.07.15, 10:43

Есть же shelve.

Ммм.. по описанию, похоже что надо... Попробую...

Цитата OpenGL @ 08.07.15, 10:43

В гуе это так вообще мегаудобно делается.

Эх Даже если отбросить то, что гуй не всегда доступен, есть такой момент: сколько я этих гуёв видел, обычно всё какое-то урезанное. (TortoiseSVN, TortoiseGit, плагины к разным IDE -- практически всё не пригодно к использованию). TortoiseHg поэтому даже не пытался смотреть. Думаешь, стоит попробовать?

Добавлено 09.07.15, 07:59

Цитата OpenGL @ 09.07.15, 07:47

Цитата negram @ 09.07.15, 07:31

Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\

Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать.

Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна, во вторых:

Цитата

A local tag is a convenience identifier that is not revision controlled, does not propagate with other changes, and lives in the

looks like not an option.

Добавлено 09.07.15, 08:06

Цитата applegame @ 08.07.15, 11:39

git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.

Вот только если в гите, скорее всего, таки можно нагуглить как что-то сделать, в hg упираешься в то, что -- низя

Сообщение отредактировано: negram - 09.07.15, 14:16

Прикреплённая картинка

Цитата negram @ 09.07.15, 07:54

остальное предлагается поправить и добавить.

Не совсем понимаю "поправить". Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Если да, то в thg такого не сделать. Но выбрать для коммита отдельные части diff-а (например, менял пятую и двадцатую строки, а коммитить решил только пятую) я могу.

Цитата negram @ 09.07.15, 07:54

Думаешь, стоит попробовать?

Не знаю. Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. По крайней мере в thg можно удобно сделать большинство из того, что ты записал в минусы hg record. А окно shelve выглядит как на скриншоте - перемещаешь файлы или их части направо в выбранный shelve или наоборот.

Прикреплённая картинка

Цитата negram @ 09.07.15, 07:54

Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна

Всё равно не вижу проблемы. Ну есть ревизии в репе, и что? Не мешают же. Вот с тегами засада, да. Придётся вводить префиксы, чтобы в разных ветках они обязательно назывались по-разному. Но в таком случае я бы в первую очередь подумал, как решить ту же задачу, которую ты решаешь в гите частичным клонированием репозитория со своими тегами.

Цитата OpenGL @ 09.07.15, 10:21

Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()?

Ага. Редко требуется, конечно, но бывает.

Цитата OpenGL @ 09.07.15, 10:21

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

Ошибаешься, у меня нет априоных установок на этот счёт. Diff я к примеру в 95% случаев смотрю в kompare и не понимаю соседей которые делают ревью с помощью hg diff. Просто я после нескольких лет сидения на TortoiseSVN перешел на консольный SVN-клиент. И внезапно он реально оказался более послушным. Хотя, судя по скриншотам, у тебя система в которой отсутствует автодополнение и подсветка в консоле, так-что наверное там просто выбора нет.

Цитата OpenGL @ 09.07.15, 10:21

Всё равно не вижу проблемы. Ну есть ревизии в репе, и что?

Ну я не нашел оправдания тому, чтоб во все проекты пихать баги-фичи всех проектов (к тому же их ещё и клиент видит; ну специфика у нас такая).

А не спорьте! Fossil лучше всех. Все достоинства в одном файле и никаких недостатков.

А у нас на работе щас Perforce стоит. До этого работал с Mercurial и SVN. Поначалу вообще в этом Перфорсе непривычно, сейчас немного уже привык в нем.

Вообще то, perforce, во первых стоит деньги, во вторых закрытая система, да и еще клиент-сервер.

А fossil открытая, бесплатная и распределённая. При этом, в отличии от тот же git у fossil все преимущества клиент-сервер архитектуры сохраняются.

Во, хороший холивор.
Я все еще с удовольствием держу свои проекты в mercurial. И все также сильно страдаю, когда приходится работать с чужими гитхабовскими репами. Особо бесит оторванная башка (detached head), при малейшем отклонении от свежепрочитанного мануала.

Сообщение отредактировано: applegame - 26.07.16, 15:46