Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.17.6.75] |
|
Страницы: (9) 1 [2] 3 4 ... 8 9 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Велик и могуч русский язык - иногда в нём "все" означает "большинство" Цитата negram @ - медленный. очень. очень-очень прям -- даже на сравнительно небольших репозиториях как и всё, что на питоне Не знаю. В целом скорость устраивает. Вероятно, потому, что я исключительно через гуй работаю. Так что ок, запишем в плюс гиту. Цитата negram @ - удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую. Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно. А что это? Беглый гуглинг не помог. А под этим что понимается? Ручное задание этих пометок файлам что ли? Цитата negram @ hg record -- урезанный -- конкретно урезанно: -- нельзя перейти в режим редактирования патча -- нельзя разбить патч на более мелкие части -- нельзя временно пропустить патч, чтоб посмотреть что ещё в этом файле изменилось, чтоб принять решение по данному чанку В консоли - может быть. В TortoiseHG при коммите разве что сами патчи нельзя редактировать. Но коммитить только часть патча и смотреть всё, что поменялось в файле вполне можно. Цитата negram @ - git stash порой тоже не хватает. приходится делать hg diff > patch && some shit && patch -p1 < patch Есть же shelve. В гуе это так вообще мегаудобно делается. Ты про hg rollback? Имхо, нафиг не надо - проще просто обновиться к нужной ревизии, а все ошибочные коммиты удалить или пометить секретными. Цитата applegame @ а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/ Или постоянные "шозанах", стандартное объяснение которых сводится к "это не баг - это фича". Например, вот. Ну и на том же хабре в статьях-комментах периодически проскакивают советы "как надо делать нечто, чтобы не сломать репозиторий". Для hg таких советов я не припомню, да и вообще слабо представляю, как его можно сломать случайно. |
Сообщ.
#17
,
|
|
|
Цитата Total Physical Source Lines of Code (SLOC) = 310,135 Это - маленький. Едва приближается к среднему. |
Сообщ.
#18
,
|
|
|
M Поменял название темы |
Сообщ.
#19
,
|
|
|
Цитата Бобёр @ Дык, речь шла о "сравнительно небольших". Ну посмотрим через годик будут ли заметны тормоза. Это - маленький. Едва приближается к среднему. |
Сообщ.
#20
,
|
|
|
Чем мне нравится в hg, так это то, что его завел и работаешь над проектом без головной боли, а в git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.
Нет у меня желания углубляться в тонкости "как оно работает". git меня заставляет углубляться, hg нет. А так в целом git - няшка, особенно github. |
Сообщ.
#21
,
|
|
|
Мм. Вероятно, не устарело, но я так и не понял проблемы Вроде, через gitk очень даже показывается что надо
Всё ж не стоит использовать худ.литературу как мануал Пока я вижу, что hg достаточно далёк от функционала git-а. Причём, это касается именно повседневной работы, уже не говоря о таких извращениях как например rerere push? Хотя, у меня чаще тормозит pull (обе эти команды занимают 5-20 секунд). На той неделе много раз пришлось клонировать репу, так это занимало по нескольку минут. А репозиторий-то -- всего 500K строк в сумме. Добавлено Цитата OpenGL @ Цитата negram @ - удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую. Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно. Мне вот как-раз такое и надо было: есть несколько проектов, с одной кодовой базой, но иногда разными плюшками и разной релизовой жизнью. Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ |
Сообщ.
#22
,
|
|
|
Цитата negram @ Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать. |
Сообщ.
#23
,
|
|
|
Цитата OpenGL @ Ответ сразу на оба вопроса картинкой, ибо расписывать долго. В кратце: изменения в коммит можно набирать в несколько этапов. Причём не файлами, а отдельными патчами. Алсо помогает при мерже, если произошли конфликты: всё, что нормально смержилось сразу добавляется в коммит (staged), остальное предлагается поправить и добавить. Добавлено Цитата OpenGL @ Ммм.. по описанию, похоже что надо... Попробую... Есть же shelve. Цитата OpenGL @ Эх Даже если отбросить то, что гуй не всегда доступен, есть такой момент: сколько я этих гуёв видел, обычно всё какое-то урезанное. (TortoiseSVN, TortoiseGit, плагины к разным IDE -- практически всё не пригодно к использованию). TortoiseHg поэтому даже не пытался смотреть. Думаешь, стоит попробовать? В гуе это так вообще мегаудобно делается. Добавлено Цитата OpenGL @ Цитата negram @ Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать. Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна, во вторых: Цитата looks like not an option. A local tag is a convenience identifier that is not revision controlled, does not propagate with other changes, and lives in the Добавлено Цитата applegame @ Вот только если в гите, скорее всего, таки можно нагуглить как что-то сделать, в hg упираешься в то, что -- низя git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx. Прикреплённая картинка
|
Сообщ.
#24
,
|
|
|
Цитата negram @ остальное предлагается поправить и добавить. Не совсем понимаю "поправить". Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Если да, то в thg такого не сделать. Но выбрать для коммита отдельные части diff-а (например, менял пятую и двадцатую строки, а коммитить решил только пятую) я могу. Цитата negram @ Думаешь, стоит попробовать? Не знаю. Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. По крайней мере в thg можно удобно сделать большинство из того, что ты записал в минусы hg record. А окно shelve выглядит как на скриншоте - перемещаешь файлы или их части направо в выбранный shelve или наоборот. Прикреплённая картинка
Цитата negram @ Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна Всё равно не вижу проблемы. Ну есть ревизии в репе, и что? Не мешают же. Вот с тегами засада, да. Придётся вводить префиксы, чтобы в разных ветках они обязательно назывались по-разному. Но в таком случае я бы в первую очередь подумал, как решить ту же задачу, которую ты решаешь в гите частичным клонированием репозитория со своими тегами. |
Сообщ.
#25
,
|
|
|
Цитата OpenGL @ Ага. Редко требуется, конечно, но бывает.Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Цитата OpenGL @ Ошибаешься, у меня нет априоных установок на этот счёт. Diff я к примеру в 95% случаев смотрю в kompare и не понимаю соседей которые делают ревью с помощью hg diff. Просто я после нескольких лет сидения на TortoiseSVN перешел на консольный SVN-клиент. И внезапно он реально оказался более послушным. Хотя, судя по скриншотам, у тебя система в которой отсутствует автодополнение и подсветка в консоле, так-что наверное там просто выбора нет.Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. Цитата OpenGL @ Ну я не нашел оправдания тому, чтоб во все проекты пихать баги-фичи всех проектов (к тому же их ещё и клиент видит; ну специфика у нас такая). Всё равно не вижу проблемы. Ну есть ревизии в репе, и что? |
Сообщ.
#27
,
|
|
|
А у нас на работе щас Perforce стоит. До этого работал с Mercurial и SVN. Поначалу вообще в этом Перфорсе непривычно, сейчас немного уже привык в нем.
|
Сообщ.
#28
,
|
|
|
Вообще то, perforce, во первых стоит деньги, во вторых закрытая система, да и еще клиент-сервер.
А fossil открытая, бесплатная и распределённая. При этом, в отличии от тот же git у fossil все преимущества клиент-сервер архитектуры сохраняются. |
Сообщ.
#29
,
|
|
|
Во, хороший холивор.
Я все еще с удовольствием держу свои проекты в mercurial. И все также сильно страдаю, когда приходится работать с чужими гитхабовскими репами. Особо бесит оторванная башка (detached head), при малейшем отклонении от свежепрочитанного мануала. |
Сообщ.
#30
,
|
|
|
|