Pull to refresh

Comments 82

Мне бОльшую часть времени приходится использовать SVN, но за некоторые бенефиты(в т.ч. и вышеописанные оффлайн коммиты) Mercurial более по душе.

В статье всё сухо и по делу, без лишних преукрашиваний. Спасибо!
Простите, я правильно понял, что ваш личный опыт заключается в следующем?
  • Вы нашли классный плагин для visual studio
  • Вы выбрали провайдера для репозитория (вот уж не думал, кстати, что проприетарные компании имеют внешние репозитории на публичных сервисах)
  • нашли hg convert svn
hg convert находится очень быстро, но почти везде написано, что с TortoiseHG он не работает. Когда я это читал, у меня TortoiseHG ещё не стоял, а когда встал, уже в голове переключатель стоял на «не работает».

Репозиторий компании расположен в компании, я пишу код не только для компании, а вообще.

А в целом да, статья о том, что всё не так печально, как пишут в Интернетах, и можно без ломок переходить с SVN на Mercurial.
почти везде написано, что с TortoiseHG он не работает
Хрень везде написана. Я, кстати, её не видел ни разу. Ткните меня носом, пожалуйста. TortoiseHg в себе содержит полноценную версию обычного консольного mercurial, и является лишь оболочкой к нему. Всё, что работает в mercurial, работает в TortoiseHg.

Вы не обижайтесь, но я скромно полагаю, что статья ваша ни о чём, в таком случае. Это и так уже общеизвестный факт, даже на хабре писали
А вы прочитайте текст статьи и всё встанет на свои места. Там и ссылка есть в ответ на ваш вопрос, и область применения озвучена.

Вы не обижайтесь, но лучше читать текст статьи перед её комментированием и быть в теме. Чуть ниже на это обращает Ваше внимание и другой комментатор.
Представьте себе, прочитал. Если бы не прочитал, то бы не оставил и первого комментария. По ссылке на «боевую вики» я никаких упоминаний TortoiseHG не нашёл. Там есть фраза
Note that you can't do this with the Win32 Mercurial binaries — there's no way to install the Subversion bindings into its built-in Python library. So you'll need to use a Mercurial installed on top of a stand-alone Python, and you may also need to do something like «set HG=python c:\Python25\Scripts\hg» to override the default Win32 binaries if you have those installed also

но я не могу поверить, что необходимость установить сначала питон, а потом уже mercurial, и (возможно) выполнить одну команду, вы назвали плясками.
Возможно, легче будет поверить, если попробуете устрицы. Которые не работают с пробелами в именах путей, не документированы для Windows 7 и что-нибудь ещё, уникальное.
о_О Я бы ещё понял грибы, но устрицы?!
Команда TortoiseHG специально включила в дистрибутив Subversion bindings чтобы люди не мучались. У них на битбукете баг был для этого. Теоретически даже должен был заработать hgsubversion но мне это не удалось.
Касательно комментария ниже, вы либо случайно написали в статье «плагины для Mercurial» вместо «плагины под виндовый TortoiseHG», либо не понимаете, что это разные вещи.
Зато теперь я понимаю, откуда у Вас лычка комментатор =)

Заканчивать каждое предложение статьи «в Windows с одним лишь установленным TortoiseHG» негуманно, на мой взгляд. Считаю, что вполне достаточно это написать один раз в самом начале.
Лычка комментатор у меня от того, что я оставил более пяти комментариев, получивших рейтинг +50, а вы что подумали?

Не утрируйте, я не предлагал этого сделать, а лишь указал на то, что mercurial != TortoiseHg
Я подумал, что Вы пишете много, гладко и логично. Но немного в стороне от реальности.

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

На что лучше заменить
Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится,
, чтобы избежать разночтений? Напомню, что Вы чуть выше копипастили текст из документации о невозможности расширять функциональность бинарника hg библиотеками на Питоне, это именно то, что я написал.
Так всё-таки об этом? А я уже думал, что вы имеете в виду плагины к самому TortoiseHg (на манер TortoiseSVN). Видимо, опять не так вас понял.

Ну напишите «Для работы с Mercurial под Windows нужен только TortoiseHG, однако может оказаться так, что для написания расширений придётся немного поплясать с бубном, питоном и системными переменными»

Мне сейчас всё равно уже, если честно, потому что спать пора.

Спокойной ночи :)
TortoiseHG это убогая обертка, написанная на питоне, и из-за этого, видимо, пихающая в трей иконку оверлей сервера… В-общем, рядом с TortoiseSVN она выглядит как убогая поделка, и это печально :(
угу. tortoiseproc.exe, вон, иконку в трей не кладёт — и её незаметно. Вне зависимости от кол-ва отжираемой оперативки.
Нет, еще вот:
Но с одним нюансом, у MS не работает русский в комментариях к коммитам.
Сразу хочу договориться. Я сторонник политики разработки Microsoft […]


Я рыдал. И эти фразы не выдраны из контекста.

По-моему, автор имел в виду «писать плагины под виндовый TortoiseHG»
Хороший плагин тут же (±6 месяцев) внедрят в GUI.
вас послушать, так GUI версия вполне может появиться за полгода до создания плагина :)
да, вот shelve же есть (хотя не исключено, что это обёртка над MQ).
используем mercurial почти год, взамен SVN — полет нормальный, более гладкий

так же mercurial очень помогает когда есть сторонний проект на SVN (read only доступ) в который хочется вносить изменения и регулярно получать обновления
А мне приходится сотрудничать с другими разработчиками сидящими на СВНе. По этому я нашёл плагин позволяющий мне работать в меркуриале, а push-ить всё в центральный СВН-овский сервер.
Летал в Египет — неделю работал в оффлайне (конечно не полный день, а только после двух ужинов :) ), прилетел домой и все коммиты в центральный СВН выгрузил :)

mercurial.selenic.com/wiki/HgSubversion
За неделю на Убунте глюков пока не обнаружил. Хотя бранчи ещё не до конца осилил — надо разбираться.
Да, я планировал написать о том, что у Mercurial на деле больше бенефитов, чем один лишь оффлайн, и сделать это с повывертом, типа «но если им попользовать чуть дольше...», но судьба распорядилась иначе и опубликовала половину статьи ;)

Есть масса статей про переезд, но они не о том. Много буков про штуки, которые обычному разработчику SVN не требуются. Ему требуется, чтобы «всё было как раньше, только в два раза лучше».
А что мешает отредактировать статью и добавить всё то, что хотелось?
Я не планировал её закончить за один раз =)
Пока не запретят редактировать, буду дописывать.

На новой Мембране правильно сделали создание статей, там публикация расположена очень далеко от кнопки «сохранить».
Есть же кнопочка переместить в черновики…
Я ею и пользовался, пока писал. А потом посреди правок случайно нажал опубликовать.
Кнопка «сохранить» должна быть единственной сохраняющей. А тип сохранения должен быть там же примерно, где и раздел, куда публикуешь.
К сожалению под виндой я его заработать заставить так и не смог.
Не статья, а сплошь эмоции. Автор, кажется, не определился, что же именно хочет рассказать…

Скажем, что там с неделями тянущимися бранчами, которые потом трудно мержить? Это где проблемой стало? svn или hg?
Я старался группировать по абзацам =) Проблемой стало в SVN. На Хабре перевели статью Спольски, например.

Проблема не в недельных бранчах, а в отсутствии мерджей транка в бранч. В таких случаях действительно можно поседеть, пока бранч будешь мерджить обратно в транк. И не только из-за горы merge-конфликтов.
Ага.

Иными словами, это та самая проблема, что легко решается ежедневным rebase на основную ветку в каком-нибудь git? :)
Когда появится настоящий VisualHG типо VisualSVN, тогда подумаем…
Плагин, на который я дал ссылку, не хуже VisualSVN. В силу большей функциональности самого Mercurial, он получается более громоздким, но к этому привыкаешь быстро.

Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.
Дело в том, что все HG плагины для VS — это SCC провайдеры.

А SCC интерфейс изначально делался для Visual SourceSafe, отсюда их потенциальная ущербность — анахроническая необходимость постоянно зачем-то чекаутить файлы перед редактированием, отсутствие статуса по директориям, какие-то маразматические записи в файле-проекта…

У VisualSVN всего этого «богатого наследия» нет. Поэтому и работает хорошо, и моск не парит.
Я пару лет активно использовал VisualSVN и сейчас, около года, использую VisualHG. С VisualHG проблем заметно меньше. Это практические наблюдение.
VisualSVN некорректно работает, если вы используете VSS или ещё какой-нить SCC плугин.
Я не использовал ни тогда, ни сейчас, VSS, в частности, и другую VCS, вообще.
Вам повезло. Если на работе используешь SCC провайдер, а для опен сорс вечерами — VisualSVN начинаются проблемы.
А какая версия? У меня 1.7.7, параллельно с HgScc работает нормально.

Они убрали 1.7.7 из даунлоада, чтобы народ покупал новую версию для десятой студии. Я раздумывал на тему апгрейда, но в двойке для меня кроме иконок ничего не поменялось.
Баг такой: если хоть один проект в солюшене использует SVN, то студия перестает обращаться к SCC. Нет индикации check-out, например.
А, с таким я никогда не сталкивался =) У меня все проекты гомогенные. А даже если бы и были гетерогенными, то пользовался бы встроенными в HG средствами для работы с внешними репозиториями на SVN. В таком случае офлайн-фича Mercurial никуда не теряется из-за одного проекта на Subversion.

Если в проекте очень длинная история, импортировать можно не всю, а какую-то относительно свежую часть шапки. Иногда промахиваешься с глубиной, но так лучше, чем без истории вообще или с двухдневным ожиданием импорта.
Если бы в HgScc еще можно было бы статусные иконки поменять (замки втопку), да контекстные меню наружу вывернуть(за коммитом далеко лазить), ну и статус по папкам — уже завтра бы перешел на HG ;)
У HG можно жать на кнопку коммита в тулбаре (а ещё лучше биндить хоткей), потому что, как я понял из документации, коммит идёт сразу всему, а не только выбранному файлу.

Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.
Вообще-то есть такой плагин. И называется VisualHG, как ни странно. Мне он нравится больше HGSCC
Когда вы работаете в Проводнике Windows, удобнее пользоваться инструментом, который расположен «в Проводнике». Для повседневной работы в IDE или в консоли он не нужен, ясное дело.
Затем чтобы ваша секретарша, которая документацию правит, не стала резко хакером, а нежно клацала мышкой накрашенным ало-красным ногтиком %)
В больших проектах — большие интересные коммиты. Их удобнее рассматривать в GUI потому как влезает больше текста, строчки лучше отделены друг от друга, есть иконки, чекбоксы, кнопочки и контекстное меню. Это тривиально быстрее, чем делать из консоли. Это я вам говорю как человек, который много пользуется как консольной, так и GUI версией subversion. На простых задачах консоль лучше. Но если идет активная разработка и десяток программистов что-то меняют, то удобнее работать с GUI. Это из личной практики, возможно у другого человека все будет с точностью до наоборот :). В любом случае ведь лучше, когда есть выбор? :)
А что такое оффлайн коммиты и для чего именно они нужны? Вы можете осветить этот вопрос?
Чтобы работу структурировать и баги в одну кучу не мешать, когда в оффлайне
а как именно? где можно об этом подробнее почитать?
мне например удобно каждую выполненную подзадачу коммитить отдельно с комментарием, что именно сделал. Но это опять таки, дело вкуса.
Это один из больших и серьезных преимуществ распределенного репозитория по отношению к централизованному: git/hg перед svn. Оффлайн коммит позволяет вам делать commit без подключения к серверу, «локально». Это удобно когда мы хотим придерживаться мелких, хорошо комментированных коммитов при этом сидим с ноутбуком в метро / на конференции / в самолете / etc. А при наличии интернета мы отгружаем все изменения скопом.

Второй вариант применения — это когда мы решаем БОЛЬШУЮ задачу и хотим сделать несколько мелких логических коммитов. Возможность делать коммиты локально не ломая автобилд позволяет все собрать, оттестировать а потом положить на сервер — это удобнее, чем делать ветку. Не могу сказать что методологически правильнее — но по моему опыту удобнее :(.
У нас есть кучка замечательных систем
CVS
SVN
GIT



А надо столько?
И это еще ладно, каждый использует свое… но их все больше и больше. Как же жить дальше? Менять систему каждый год?
А если использовать параллельно несколько репозитариев?
Ой мама, страшненько.
Как же жить дальше? Менять систему каждый год?
вас никто не заставляет
Нет, ясное дело, что менять никто и не будет. Но тогда вопрос — зачем так много вариантов?
Конечно мы все хотим новое, и это интересно. Новая система, новые идеи. Прогресс.

Но тогда вместо написания кода по сути мы только и занимаемся девелопментом систем, которые якобы улучшают поддержку кода (да, наверно это так).

А сам код в это время никто не пишет.

PS. В жизни от перехода с CVS на SVN толку почти не было, а гимора хватило — новый репозиторий, конвертация, переучивание человеков… Единственный плюс — копирование комментариев при move/merge. Но это раз в год…
зачем так много вариантов?
люди пишут другие инструменты потому, что существующие не подходят по тем или иным причинам. Ваш К.О.
Новая система, новые идеи. Прогресс.
прогресс — это не когда всё новое, а когда экономятся ресурсы.
тогда вместо написания кода по сути мы только и занимаемся девелопментом систем, которые якобы улучшают поддержку кода (да, наверно это так).
А сам код в это время никто не пишет.
передёргиваете.
В жизни от перехода с CVS на SVN толку почти не было
А вот от перехода на DVCS (Mercurial в частности) толк есть. И изрядно. Навскидку — merge стал незаметным, бранчами стали пользоваться, жить стало проще и веселей. И так далее.
Кого-то существующие системы не устраивают и он пишет свою. Если причины, по которым не устраивает не «закидон», а многим доставляют реальное неудобство, то решение «для себя» становится популярным, но по разным причинам все на него не переходят. Не последнюю роль играет, что то, что удобно для одних задач, может быть не удобным для других.
Не нашёл GUI-клиента вменяемого и все в один голос утверждают, то он есть только у Mercurial, и имя его TortoiseHG


Если не секрет, как не удалось найти TortoiseGit? Он вроде как первой ссылкой в гугле идет?
Это порт TortoiseSVN, слишком много возни с мышкой.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.
> Не нашёл GUI-клиента вменяемого
слишком много возни с мышкой


Не совсем вас понимаю — а разве GUI это не возня с мышкой? Как вы себе представляете «вменяемый» GUI клиент? TortoiseSVN — это «вменяемый» GUI-клиент для subversion или нет?
Возня с мышкой это в два-три раза больше телодвижений.
Коммит без просмотра диффов разумно делать только для очень коротких изменений.

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 как вы и хотите? :(
Вы случайно не родственник товарищу, который мне выше раз 7 написал, что я чего-то не понимаю из детского мануала к Mercurial или TortoiseHG? Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт. Надеюсь, я достаточно внятно выразился, что «не можете запомнить», «не понимаете» и прочие подростковые способы ведения диалога его закончат.

Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)

В зависимости от ситуации я использую стрелки или не использую — зависимость не исследовал, потому что на автомате действую. Предположу, что зависит от активного контрола, от действий в окне дифа и количества файлов. Если фокус в окне дифа, стрелки будут крутить его, а не идти по списку с файлами, поэтому от клика иногда не уйдёшь. Но в любом случае мышка остаётся в руке, потому что колесом крутится окно с дифом. Стрелки жмутся левой рукой.

Что имеем с 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 (слева на иллюстрации)?
Я думал, вы видели окно коммита в TortoiseHG =)

Увы, mercurial я не пользовался — слишком много технологий, все не изучишь. То, что вы показали практически не отличается от того, что я заскриншотил до этого. При этом можно использовать любой diff, а не тот огрызок что у TortoiseHG ^_^. Сложные переносы блоков и рефакторинг вы плюсиками и минусиками замучаетесь изучать.
Сложные переносы блоков я не буду исследовать через окно коммита. По большому счёту, перед коммитом проводится последняя инспекция на предмет «а не забыли ли мы скальпель у пациента внутри?»

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

Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.

А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.
Познакомившись с mercurial меня не покидает впечатление, что вся разработка mercurial ведется под лозунгом «наш ответ Линусу, не ты один умеешь программировать». Но этот ответ очень проигрывает в элегантности.
Only those users with full accounts are able to leave comments. Log in, please.