Забыли упомянуть ещё одну важную и очень бурную область, телефоны.
Там тоже всё просто уже. Во всяком случае, для современных операционок Microsoft, Apple и Google.
Сложные переносы блоков я не буду исследовать через окно коммита. По большому счёту, перед коммитом проводится последняя инспекция на предмет «а не забыли ли мы скальпель у пациента внутри?»
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
Это не только к окну коммита относится. Check modifications должно работать аналогично, там тоже список файлов на потенциальный коммит. Я писал только про окно коммита, потому что часто им пользуюсь вместо Check modifications — не надо лезть в подменю, если в проводнике, плюс в VS хоткей биндится на коммит.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
Вы случайно не родственник товарищу, который мне выше раз 7 написал, что я чего-то не понимаю из детского мануала к Mercurial или TortoiseHG? Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт. Надеюсь, я достаточно внятно выразился, что «не можете запомнить», «не понимаете» и прочие подростковые способы ведения диалога его закончат.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
Как в TortoiseHG, одним левым кликом по файлу с возможностью листания клавиатурой.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
А, с таким я никогда не сталкивался =) У меня все проекты гомогенные. А даже если бы и были гетерогенными, то пользовался бы встроенными в HG средствами для работы с внешними репозиториями на SVN. В таком случае офлайн-фича Mercurial никуда не теряется из-за одного проекта на Subversion.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
А какая версия? У меня 1.7.7, параллельно с HgScc работает нормально.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
У HG можно жать на кнопку коммита в тулбаре (а ещё лучше биндить хоткей), потому что, как я понял из документации, коммит идёт сразу всему, а не только выбранному файлу.
Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.
Я ею и пользовался, пока писал. А потом посреди правок случайно нажал опубликовать.
Кнопка «сохранить» должна быть единственной сохраняющей. А тип сохранения должен быть там же примерно, где и раздел, куда публикуешь.
Когда вы работаете в Проводнике Windows, удобнее пользоваться инструментом, который расположен «в Проводнике». Для повседневной работы в IDE или в консоли он не нужен, ясное дело.
Плагин, на который я дал ссылку, не хуже VisualSVN. В силу большей функциональности самого Mercurial, он получается более громоздким, но к этому привыкаешь быстро.
Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.
Я подумал, что Вы пишете много, гладко и логично. Но немного в стороне от реальности.
Предлагаю вернуться к обсуждению текста. Вы, надеюсь, разобрались, что я написал в первом абзаце. Надеюсь так же, что поможете исправить предложение так, чтобы оно, на Ваш взгляд, не вводило в заблуждение.
На что лучше заменить
Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится,
, чтобы избежать разночтений? Напомню, что Вы чуть выше копипастили текст из документации о невозможности расширять функциональность бинарника hg библиотеками на Питоне, это именно то, что я написал.
Я старался группировать по абзацам =) Проблемой стало в SVN. На Хабре перевели статью Спольски, например.
Проблема не в недельных бранчах, а в отсутствии мерджей транка в бранч. В таких случаях действительно можно поседеть, пока бранч будешь мерджить обратно в транк. И не только из-за горы merge-конфликтов.
Зато теперь я понимаю, откуда у Вас лычка комментатор =)
Заканчивать каждое предложение статьи «в Windows с одним лишь установленным TortoiseHG» негуманно, на мой взгляд. Считаю, что вполне достаточно это написать один раз в самом начале.
Там тоже всё просто уже. Во всяком случае, для современных операционок Microsoft, Apple и Google.
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.
TortoiseSVN лучше остальных и с ним работает плагин VisualSVN. То, что всё остальное ещё хуже не значит, что TortoiseSVN предел мечтаний.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.
Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.
Кнопка «сохранить» должна быть единственной сохраняющей. А тип сохранения должен быть там же примерно, где и раздел, куда публикуешь.
В моей Вселенной про устриц может подсказать Яндекс.
Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.
Предлагаю вернуться к обсуждению текста. Вы, надеюсь, разобрались, что я написал в первом абзаце. Надеюсь так же, что поможете исправить предложение так, чтобы оно, на Ваш взгляд, не вводило в заблуждение.
На что лучше заменить , чтобы избежать разночтений? Напомню, что Вы чуть выше копипастили текст из документации о невозможности расширять функциональность бинарника hg библиотеками на Питоне, это именно то, что я написал.
Проблема не в недельных бранчах, а в отсутствии мерджей транка в бранч. В таких случаях действительно можно поседеть, пока бранч будешь мерджить обратно в транк. И не только из-за горы merge-конфликтов.
Пока не запретят редактировать, буду дописывать.
На новой Мембране правильно сделали создание статей, там публикация расположена очень далеко от кнопки «сохранить».
Заканчивать каждое предложение статьи «в Windows с одним лишь установленным TortoiseHG» негуманно, на мой взгляд. Считаю, что вполне достаточно это написать один раз в самом начале.