Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Мне бОльшую часть времени приходится использовать SVN, но за некоторые бенефиты(в т.ч. и вышеописанные оффлайн коммиты) Mercurial более по душе.
В статье всё сухо и по делу, без лишних преукрашиваний. Спасибо!
В статье всё сухо и по делу, без лишних преукрашиваний. Спасибо!
hg convert находится очень быстро, но почти везде написано, что с TortoiseHG он не работает. Когда я это читал, у меня TortoiseHG ещё не стоял, а когда встал, уже в голове переключатель стоял на «не работает».
Репозиторий компании расположен в компании, я пишу код не только для компании, а вообще.
А в целом да, статья о том, что всё не так печально, как пишут в Интернетах, и можно без ломок переходить с SVN на Mercurial.
Репозиторий компании расположен в компании, я пишу код не только для компании, а вообще.
А в целом да, статья о том, что всё не так печально, как пишут в Интернетах, и можно без ломок переходить с SVN на Mercurial.
А вы прочитайте текст статьи и всё встанет на свои места. Там и ссылка есть в ответ на ваш вопрос, и область применения озвучена.
Вы не обижайтесь, но лучше читать текст статьи перед её комментированием и быть в теме. Чуть ниже на это обращает Ваше внимание и другой комментатор.
Вы не обижайтесь, но лучше читать текст статьи перед её комментированием и быть в теме. Чуть ниже на это обращает Ваше внимание и другой комментатор.
Возможно, легче будет поверить, если попробуете устрицы. Которые не работают с пробелами в именах путей, не документированы для Windows 7 и что-нибудь ещё, уникальное.
Просто наши Вселенные слабо пересекаются =)
В моей Вселенной про устриц может подсказать Яндекс.
В моей Вселенной про устриц может подсказать Яндекс.
Команда TortoiseHG специально включила в дистрибутив Subversion bindings чтобы люди не мучались. У них на битбукете баг был для этого. Теоретически даже должен был заработать hgsubversion но мне это не удалось.
Зато теперь я понимаю, откуда у Вас лычка комментатор =)
Заканчивать каждое предложение статьи «в Windows с одним лишь установленным TortoiseHG» негуманно, на мой взгляд. Считаю, что вполне достаточно это написать один раз в самом начале.
Заканчивать каждое предложение статьи «в Windows с одним лишь установленным TortoiseHG» негуманно, на мой взгляд. Считаю, что вполне достаточно это написать один раз в самом начале.
Я подумал, что Вы пишете много, гладко и логично. Но немного в стороне от реальности.
Предлагаю вернуться к обсуждению текста. Вы, надеюсь, разобрались, что я написал в первом абзаце. Надеюсь так же, что поможете исправить предложение так, чтобы оно, на Ваш взгляд, не вводило в заблуждение.
На что лучше заменить
Предлагаю вернуться к обсуждению текста. Вы, надеюсь, разобрались, что я написал в первом абзаце. Надеюсь так же, что поможете исправить предложение так, чтобы оно, на Ваш взгляд, не вводило в заблуждение.
На что лучше заменить
Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится,, чтобы избежать разночтений? Напомню, что Вы чуть выше копипастили текст из документации о невозможности расширять функциональность бинарника hg библиотеками на Питоне, это именно то, что я написал.
TortoiseHG это убогая обертка, написанная на питоне, и из-за этого, видимо, пихающая в трей иконку оверлей сервера… В-общем, рядом с TortoiseSVN она выглядит как убогая поделка, и это печально :(
Нет, еще вот:
Я рыдал. И эти фразы не выдраны из контекста.
Но с одним нюансом, у MS не работает русский в комментариях к коммитам.
Сразу хочу договориться. Я сторонник политики разработки Microsoft […]
Я рыдал. И эти фразы не выдраны из контекста.
используем mercurial почти год, взамен SVN — полет нормальный, более гладкий
так же mercurial очень помогает когда есть сторонний проект на SVN (read only доступ) в который хочется вносить изменения и регулярно получать обновления
так же mercurial очень помогает когда есть сторонний проект на SVN (read only доступ) в который хочется вносить изменения и регулярно получать обновления
А мне приходится сотрудничать с другими разработчиками сидящими на СВНе. По этому я нашёл плагин позволяющий мне работать в меркуриале, а push-ить всё в центральный СВН-овский сервер.
Летал в Египет — неделю работал в оффлайне (конечно не полный день, а только после двух ужинов :) ), прилетел домой и все коммиты в центральный СВН выгрузил :)
mercurial.selenic.com/wiki/HgSubversion
За неделю на Убунте глюков пока не обнаружил. Хотя бранчи ещё не до конца осилил — надо разбираться.
Летал в Египет — неделю работал в оффлайне (конечно не полный день, а только после двух ужинов :) ), прилетел домой и все коммиты в центральный СВН выгрузил :)
mercurial.selenic.com/wiki/HgSubversion
За неделю на Убунте глюков пока не обнаружил. Хотя бранчи ещё не до конца осилил — надо разбираться.
На SVN весь репозиторий или только какая-то часть?
Во втором случае всё вроде как можно сделать нативно(без плагинов) при помощи Subrepository: mercurial.selenic.com/wiki/Subrepository#SVN_subrepositories
Во втором случае всё вроде как можно сделать нативно(без плагинов) при помощи Subrepository: mercurial.selenic.com/wiki/Subrepository#SVN_subrepositories
Да, я планировал написать о том, что у Mercurial на деле больше бенефитов, чем один лишь оффлайн, и сделать это с повывертом, типа «но если им попользовать чуть дольше...», но судьба распорядилась иначе и опубликовала половину статьи ;)
Есть масса статей про переезд, но они не о том. Много буков про штуки, которые обычному разработчику SVN не требуются. Ему требуется, чтобы «всё было как раньше, только в два раза лучше».
Есть масса статей про переезд, но они не о том. Много буков про штуки, которые обычному разработчику SVN не требуются. Ему требуется, чтобы «всё было как раньше, только в два раза лучше».
К сожалению под виндой я его заработать заставить так и не смог.
Не статья, а сплошь эмоции. Автор, кажется, не определился, что же именно хочет рассказать…
Скажем, что там с неделями тянущимися бранчами, которые потом трудно мержить? Это где проблемой стало? svn или hg?
Скажем, что там с неделями тянущимися бранчами, которые потом трудно мержить? Это где проблемой стало? svn или hg?
Я старался группировать по абзацам =) Проблемой стало в SVN. На Хабре перевели статью Спольски, например.
Проблема не в недельных бранчах, а в отсутствии мерджей транка в бранч. В таких случаях действительно можно поседеть, пока бранч будешь мерджить обратно в транк. И не только из-за горы merge-конфликтов.
Проблема не в недельных бранчах, а в отсутствии мерджей транка в бранч. В таких случаях действительно можно поседеть, пока бранч будешь мерджить обратно в транк. И не только из-за горы merge-конфликтов.
Когда появится настоящий VisualHG типо VisualSVN, тогда подумаем…
Плагин, на который я дал ссылку, не хуже VisualSVN. В силу большей функциональности самого Mercurial, он получается более громоздким, но к этому привыкаешь быстро.
Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.
Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.
Дело в том, что все HG плагины для VS — это SCC провайдеры.
А SCC интерфейс изначально делался для Visual SourceSafe, отсюда их потенциальная ущербность — анахроническая необходимость постоянно зачем-то чекаутить файлы перед редактированием, отсутствие статуса по директориям, какие-то маразматические записи в файле-проекта…
У VisualSVN всего этого «богатого наследия» нет. Поэтому и работает хорошо, и моск не парит.
А SCC интерфейс изначально делался для Visual SourceSafe, отсюда их потенциальная ущербность — анахроническая необходимость постоянно зачем-то чекаутить файлы перед редактированием, отсутствие статуса по директориям, какие-то маразматические записи в файле-проекта…
У VisualSVN всего этого «богатого наследия» нет. Поэтому и работает хорошо, и моск не парит.
Я пару лет активно использовал VisualSVN и сейчас, около года, использую VisualHG. С VisualHG проблем заметно меньше. Это практические наблюдение.
VisualSVN некорректно работает, если вы используете VSS или ещё какой-нить SCC плугин.
Я не использовал ни тогда, ни сейчас, VSS, в частности, и другую VCS, вообще.
А какая версия? У меня 1.7.7, параллельно с HgScc работает нормально.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
2.0.3
Баг такой: если хоть один проект в солюшене использует SVN, то студия перестает обращаться к SCC. Нет индикации check-out, например.
А, с таким я никогда не сталкивался =) У меня все проекты гомогенные. А даже если бы и были гетерогенными, то пользовался бы встроенными в HG средствами для работы с внешними репозиториями на SVN. В таком случае офлайн-фича Mercurial никуда не теряется из-за одного проекта на Subversion.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
Если бы в HgScc еще можно было бы статусные иконки поменять (замки втопку), да контекстные меню наружу вывернуть(за коммитом далеко лазить), ну и статус по папкам — уже завтра бы перешел на HG ;)
У HG можно жать на кнопку коммита в тулбаре (а ещё лучше биндить хоткей), потому что, как я понял из документации, коммит идёт сразу всему, а не только выбранному файлу.
Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.
Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.
Вообще-то есть такой плагин. И называется VisualHG, как ни странно. Мне он нравится больше HGSCC
Вам тот же ответ
Поздно уже, но посмотрите на SmartGit :)
Зачем нужен GUI к VCS? оО
Когда вы работаете в Проводнике Windows, удобнее пользоваться инструментом, который расположен «в Проводнике». Для повседневной работы в IDE или в консоли он не нужен, ясное дело.
Затем чтобы ваша секретарша, которая документацию правит, не стала резко хакером, а нежно клацала мышкой накрашенным ало-красным ногтиком %)
В больших проектах — большие интересные коммиты. Их удобнее рассматривать в GUI потому как влезает больше текста, строчки лучше отделены друг от друга, есть иконки, чекбоксы, кнопочки и контекстное меню. Это тривиально быстрее, чем делать из консоли. Это я вам говорю как человек, который много пользуется как консольной, так и GUI версией subversion. На простых задачах консоль лучше. Но если идет активная разработка и десяток программистов что-то меняют, то удобнее работать с GUI. Это из личной практики, возможно у другого человека все будет с точностью до наоборот :). В любом случае ведь лучше, когда есть выбор? :)
А что такое оффлайн коммиты и для чего именно они нужны? Вы можете осветить этот вопрос?
Чтобы работу структурировать и баги в одну кучу не мешать, когда в оффлайне
а как именно? где можно об этом подробнее почитать?
Чуть выше давали ссылку на перевод пособия Спольски.
мне например удобно каждую выполненную подзадачу коммитить отдельно с комментарием, что именно сделал. Но это опять таки, дело вкуса.
Это один из больших и серьезных преимуществ распределенного репозитория по отношению к централизованному: git/hg перед svn. Оффлайн коммит позволяет вам делать commit без подключения к серверу, «локально». Это удобно когда мы хотим придерживаться мелких, хорошо комментированных коммитов при этом сидим с ноутбуком в метро / на конференции / в самолете / etc. А при наличии интернета мы отгружаем все изменения скопом.
Второй вариант применения — это когда мы решаем БОЛЬШУЮ задачу и хотим сделать несколько мелких логических коммитов. Возможность делать коммиты локально не ломая автобилд позволяет все собрать, оттестировать а потом положить на сервер — это удобнее, чем делать ветку. Не могу сказать что методологически правильнее — но по моему опыту удобнее :(.
Второй вариант применения — это когда мы решаем БОЛЬШУЮ задачу и хотим сделать несколько мелких логических коммитов. Возможность делать коммиты локально не ломая автобилд позволяет все собрать, оттестировать а потом положить на сервер — это удобнее, чем делать ветку. Не могу сказать что методологически правильнее — но по моему опыту удобнее :(.
У нас есть кучка замечательных систем
CVS
SVN
GIT
…
…
А надо столько?
И это еще ладно, каждый использует свое… но их все больше и больше. Как же жить дальше? Менять систему каждый год?
А если использовать параллельно несколько репозитариев?
Ой мама, страшненько.
CVS
SVN
GIT
…
…
А надо столько?
И это еще ладно, каждый использует свое… но их все больше и больше. Как же жить дальше? Менять систему каждый год?
А если использовать параллельно несколько репозитариев?
Ой мама, страшненько.
Нет, ясное дело, что менять никто и не будет. Но тогда вопрос — зачем так много вариантов?
Конечно мы все хотим новое, и это интересно. Новая система, новые идеи. Прогресс.
Но тогда вместо написания кода по сути мы только и занимаемся девелопментом систем, которые якобы улучшают поддержку кода (да, наверно это так).
А сам код в это время никто не пишет.
PS. В жизни от перехода с CVS на SVN толку почти не было, а гимора хватило — новый репозиторий, конвертация, переучивание человеков… Единственный плюс — копирование комментариев при move/merge. Но это раз в год…
Конечно мы все хотим новое, и это интересно. Новая система, новые идеи. Прогресс.
Но тогда вместо написания кода по сути мы только и занимаемся девелопментом систем, которые якобы улучшают поддержку кода (да, наверно это так).
А сам код в это время никто не пишет.
PS. В жизни от перехода с CVS на SVN толку почти не было, а гимора хватило — новый репозиторий, конвертация, переучивание человеков… Единственный плюс — копирование комментариев при move/merge. Но это раз в год…
Кого-то существующие системы не устраивают и он пишет свою. Если причины, по которым не устраивает не «закидон», а многим доставляют реальное неудобство, то решение «для себя» становится популярным, но по разным причинам все на него не переходят. Не последнюю роль играет, что то, что удобно для одних задач, может быть не удобным для других.
Не нашёл GUI-клиента вменяемого и все в один голос утверждают, то он есть только у Mercurial, и имя его TortoiseHG
Если не секрет, как не удалось найти TortoiseGit? Он вроде как первой ссылкой в гугле идет?
Это порт TortoiseSVN, слишком много возни с мышкой.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.
> Не нашёл GUI-клиента вменяемого
слишком много возни с мышкой
Не совсем вас понимаю — а разве GUI это не возня с мышкой? Как вы себе представляете «вменяемый» GUI клиент? TortoiseSVN — это «вменяемый» GUI-клиент для subversion или нет?
Возня с мышкой это в два-три раза больше телодвижений.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.
TortoiseSVN лучше остальных и с ним работает плагин VisualSVN. То, что всё остальное ещё хуже не значит, что TortoiseSVN предел мечтаний.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.
TortoiseSVN лучше остальных и с ним работает плагин VisualSVN. То, что всё остальное ещё хуже не значит, что TortoiseSVN предел мечтаний.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.
Не подумайте что я тут толлю или занудствую — мне как архитектору и специалисту по процессам действительно интересен этот вопрос. Специально только что поставил TortoiseGIT 1.6.3.0, создал репозиторий, клонировал, добавил файл, сделал commit. Вот что я вижу:
Соответственно в окне коммита имеем список всех изменений. Если нас интересует ккой-то файл — кликаем на него правой кнопкой, выбираем «compare with base», изучаем diff.
Что не так с дифами? Как они, по вашем мнению, должны быть организованы с точки зрения GUI интерфейса?
Как в TortoiseHG, одним левым кликом по файлу с возможностью листания клавиатурой.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
А не правый клик -> левый клик -> левый клик (закрыть окно).
Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
Только что проверил — в окне commit нажатие Enter открывает diff, который закрывается по Esc. Листание клавиатурой стрелками вверх и вниз.
Вместо Enter можно использовать двойной клик.
Я правильно понимаю, что
Что единственная претензия к TortoiseGIT — это то, что в окне commit вы не можете запомнить, что Enter / Double Click на файл открывает Diff как вы и хотите? :(
Вместо Enter можно использовать двойной клик.
Я правильно понимаю, что
слишком много возни с мышкой.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.
заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.
Что единственная претензия к TortoiseGIT — это то, что в окне commit вы не можете запомнить, что Enter / Double Click на файл открывает Diff как вы и хотите? :(
Вы случайно не родственник товарищу, который мне выше раз 7 написал, что я чего-то не понимаю из детского мануала к Mercurial или TortoiseHG? Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт. Надеюсь, я достаточно внятно выразился, что «не можете запомнить», «не понимаете» и прочие подростковые способы ведения диалога его закончат.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)
В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.
Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.
При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.
И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.
Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт
Мои извинения, если попытка упростить вопрос вас огорчила :). Я не специально.
Что имеем с SVN/Git. Использование с мышкой описал раньше
Как я уже написал выше, вы рассматривали ранее правый клик-левый клик-левый клик. Я на это ответил, что достаточно сделать двойной клик. Меня этот момент больше всего интересует — двойной клик для получения diff'а чем не нравится?
Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее
Основной к вам вопрос: что на ваш взгляд нужно поменять в commit окне tortoisegit чтобы оно стало «вменяемым»?
Это не только к окну коммита относится. Check modifications должно работать аналогично, там тоже список файлов на потенциальный коммит. Я писал только про окно коммита, потому что часто им пользуюсь вместо Check modifications — не надо лезть в подменю, если в проводнике, плюс в VS хоткей биндится на коммит.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.
Ну вы же понимаете, что diff — это отдельная тулза. Интеграция ее в существующее GUI приложение — это очень сложная задача, на такое мало кто идет. Многие используют с TortoiseXXX внешний diff. BTW, а спозиционировать внешний diff к примеру справа от окна коммита что мешает? Смотрите, если я на windows расположу окна как на рисунке, то double click на элементе слева будет менять содержимое diff программы справа. И открываться они будут на этих местах:
BTW: Я правильно понимаю, что вы ратуете за интеграцию окна diff (справа на иллюстрации) в окно commit и check nodifications (слева на иллюстрации)?
BTW: Я правильно понимаю, что вы ратуете за интеграцию окна diff (справа на иллюстрации) в окно commit и check nodifications (слева на иллюстрации)?
Я думал, вы видели окно коммита в TortoiseHG =)
Увы, mercurial я не пользовался — слишком много технологий, все не изучишь. То, что вы показали практически не отличается от того, что я заскриншотил до этого. При этом можно использовать любой diff, а не тот огрызок что у TortoiseHG ^_^. Сложные переносы блоков и рефакторинг вы плюсиками и минусиками замучаетесь изучать.
Сложные переносы блоков я не буду исследовать через окно коммита. По большому счёту, перед коммитом проводится последняя инспекция на предмет «а не забыли ли мы скальпель у пациента внутри?»
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
Просто я считаю, что кодить без коммита много дней вредно для здоровья, поэтому в пределах любого большого рефакторинга будет несколько коммитов с максимальным интервалом в несколько часов.
Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.
А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
Познакомившись с mercurial меня не покидает впечатление, что вся разработка mercurial ведется под лозунгом «наш ответ Линусу, не ты один умеешь программировать». Но этот ответ очень проигрывает в элегантности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переезд с SVN на Mercurial: личный опыт