dervish_candela: (Dervish)
хотя я и пишу в резюме "опытный пользователь" mercurial, я регулярно сталкиваюсь с вещами, к которым вообще не знаю с какой стороны подступиться. недавно столкнулся с тем, что деревья практически во всех визуализациях строятся не то чтобы плохо, а ОМЕРЗИТЕЛЬНО. коммиты сортируются по их UID, то есть если ты держишь две или больше clone branches и не пуш/пуллишь их взаимно (!) после каждого (!) коммита, ты обречён иметь вместо дерева большой и запутанный клубок спагетти. или наушников.

"топологически эквивалентные" клубки наушников, конечно же.

вот как ты думаешь выглядит твоя ветка feature branch
feature branch.png

а вот что об этом думает твой главный репозитарий, после того как ты затянул её туда
default.png
пиздец грустное, душераздирающее зрелище.
к сожалению, так всюду. bitbucket, sourcetree, tortoise hg - одно хуже другого. ни тебе фиксированных вертикальных позиций для именованных веток, ни построения дерева по времени коммитов.

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

жаль что завяла darсs со своей чудесной patch theory. есть подозрение, что там подобные вещи были бы более интуитивно понятны, чем попытка держать в голове несколько directed acyclic graphs одновременно.
dervish_candela: (Dervish)
Generalized Driessen's Branching Model и HG Flow / Git Flow
https://bitbucket.org/yujiewu/hgflow/wiki/Home.wiki#!introduction

круто, это та самая прекрасная warm and fuzzy ситуация когда усложнение концептуальной модели ведёт одновременно к упрощению и работы (автоматизация), и понимания (унификация). хотя и для моих целей немного оверкилл (и так как я не собираюсь отказываться от физических clone branches, не очень понятно, как они будут взаимодействовать)
dervish_candela: (Default)
Скамейка объединила в себе hgtk инструменты log, status, commit и все комнады синхронизации. Куча лютых функциональных плюшек — мощные паттерны в окне фильтра, табнутый браузер репозитариев, итд. Интерфейс полностью переписан, и теперь похож на очень серьёзный инструмент, хотя в дизайне и чувствуется флавор чего-то очень опенсорсного и мозилльного, especially the legendary incomplete interface translation, it has such nostalgic air about it; и чудеснейший креативный перевод типа «протолкнуть» (push) и «после затягивания» (after pull).

Триумф! Наконец-то рабочая директория показывается в дереве выше верхушки, на месте будущего чейнджсета. Выбрать для нарисованной на экране ветки «Merge with local» оказалось куда проще, чем понять всю посвящённую веткам документацию, воссоздать дерево репозитария в голове и вбить нужную команду в шелл.

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

Вот кстати чудесный, простой как дважды два туториал показывает, как распрвляться с экспериментальными ветками-однодневками: http://csharpfeeds.com/post/98675/Experimental_branches_in_Mercurial.aspx
(а ненужную ветку можно стрипнуть или потом просто перезагрузить всю репу заново)

Нужно только помнить, что ветвей не существует :) Я серьезно. в смысле, в Hg не имеет смысла концепция ветви c технологической точки зрения, поэтому даже не стоит пытаться давать им имя, лучше скопировать всю репу и обозвать папочку как душе угодно. У этого есть один неприятный опбочный эффект — вид графа будет отличаться в зависимости от родителя рабочей директории. Если бы все незакрытые ветки торчали до самого верха то вышел бы отличный подсвечник было бы гораздо понятнее. Именно над этим я долго думал очень: как влить что-то в ветку, которой нет? Она есть, просто более новая ветка непосредственно продолжает более старую вверх вместо того, чтобы отходить вбок.

В итоге я изменил своё изначальное мнение насчёт defective by design веток в Меркуриале, заменив его на мнение об ущербности докментации и туториалов, не оговаривающих громко и явно ключевые (команда branch не создаёт веток) моменты.
dervish_candela: (Default)
«Незаменимых реп нет» ©DVCS

Поимел в Меркуриале достаточно негативный опыт с ветками. Читал много дискуссий и блогпостов.
К сожалению, работа с именованными ветками там - изначально defective by design, и попытка это как-то исправить уже доставила разрабам немало мучений, а оно всё равно - никакое. Нет, хотите ветки - пожалуйста! Скопируйте репу. Есть репа - есть ветка. Нет репы - нет проблем. Функционал присутствует, а вот свистелок и перделок нет: именованные ветки никуда не годятся. То есть они поддерживаются, конечно, но через ж. Попытка объединить две ветки у меня привела к такому ужасу в репе, что я просто склонировал её до этого кретинизма и убил (я когда нужно забываю про rollback и путаю его с backout ^^;). В общем, мы просто держим разные имена у папок репозитариев, чтобы знать, что к чему. Имен в принципе заслуживают там перманентные ветки типа dev, bugfix итп, чтобы можно было легко клонировать только релевантные области репозитария. Скажем так - меняйте имена веткам и присваивайте, пожалуйста (лучше попроще, т.к. их придется указывать буквально). Но каждой — только в отдельной, своей репе. И думаем об этом как «идентификатор репозитария, из которого пришли изменения». Господь меня больше упаси держать несколько веток в одной репе, это концептуальное сумасшествие.

Касательно веток: подумал даже, что стоит держать по ветке (репозитарию) на каждый рабочий файл (у меня кода относительно мало, поэтому по одному файлу на функциональный модуль хватает). Т.е. каждый файл открывать из своей соответствующей РК, а не из центральной. Тогда каждый файл будет меняться в только своей ветке и будет гораздо проще следить за изменениями в конкретных модулях.

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

Про даркс в интернетах отзываются достаточно жестоко («игрушка для энтузиастов»), но у них очень красивая находка со спонтанными ветками: если несколько твоих коммит мессаджей начинаются одинаково, то это и выделяется в ветку. Гениально :)

А, и — Mercurial по-прежнему не способен кодировко-агностически работать с именами файлов и добавлять что-то двухбайтовое в репу. Уныние. Хотя казалось бы, decode() - и вперёд, к звёздам...

P.S. А веб-интерфейс Битбукета оказался удобнее (и бытсрее, лол) кривого hgtk ^^;

P.P.S Также теперь это тред о написании плугина для тотала.
dervish_candela: (Default)
Если я когда-нибудь соберусь и включу остаток своих мозгов, надо будет попробовать сделать двухмерный diff для картинок. kdiff3, как легко догадаться, для этого абсолютно бесполезен :)

Кстати, интересное наблюдение для тех, кто работает в SAI и использует контроль версий (для меня, то есть): дельта-сжатие эффективно тем больше, чем больше изменения разнесены по отдельным слоям. Кроме того факта, что это экономит место (т.е. при добавлении слоя с несколькими черточками в хранилище будет записано совсем немного), есть и возможность распознать новый файл как сходный с предыдущим, используя опцию --similarity (например, для большой кисти и файла в 4 слоя мазок на каждом из слоёв даст в итоге примерно 50% сходства нового файла со старым) . Остается вопрос, почему это не работает при совмещении всех изменений на одном и том же слое. Мистика.

OpenCanvas уже использует очень эффективное сжатие, так что файлы и без того невелики.

ветки

Dec. 15th, 2009 04:22 pm
dervish_candela: (Saya)
Интересно, что идеологически правильнее - держать кучу веток в одной репе, или каждой ветке по клону и переименовать default?..

С переименовыванием веток как-то мутно - с одной стороны, оно не появляется в логе до коммита, а с другой, применяется мнгновенно. Поди разберись.

В очередной раз разобрался с мержой. Итоговый файл можно «сохранить как», что даёт шанс завершить мержу в полуавтоматическом режиме, не ковыряя вручную. Непонятно, почему мне не удалось это в прошлый раз.
dervish_candela: (Default)
О, да это, оказывается, больная тема :) Куда более, чем я подозревал. Проблема в том, что что ни у одной из систем нет зияющих дыр, на которые можно тыкнуть пальцем, поэтому дискуссии о том, что лучше, часто напоминают морской бой на полупустых досках, а участники делают кучи faux pas, обнаруживая фанбоизм и незнание матчасти (чего стоят одни атомарные коммиты. по-моему, только гит не обвиняли в ихотсутствии).

Всё это создаёт проблему выбора. Хотя я нашел несколько очень обскурных технологических деталей, по которым Bzr может быть назван менее удачным, чем Git (и тут же их забыл). Потом вкурил основательно, что Git представляет из себя весьма мощную технологически, более гибкую и продвинутую, чем Hg, систему. Но большей части пользователей ничего из этих аспектов никогда не коснётся.

Остаётся один, последний вопрос: а почему, собственно, люди выбирают меркуриал?
Примерно на этой точке я пошел гуглить и среди нескольких интересных наблюдений нашел интересный ответ: «shut up and write some code». Подумав мнут пять, я заметил, что это очень похоже на сегодняшнюю ситуацию в околофотографических кругах и множественные флеймы насчет никона и канона, в ответ на которые неизменно сыплются «заткнись и фотографируй». Иными словами, похоже что различие не стоит и выеденного яйца. Гит для большой, серьезной работы с кучей веток под линух. Hg for taking it easy под виндой. Ну и третье для тех, кто покупает пентакс. Чтобы как-то отличиться.
dervish_candela: (Default)
Где-то в одной из сетевых дискуссий попалась чья-то ехидная ремарка - мол, если уж и браться за «объекты первого класса», то почему бы не довести до абсурда и не поставить под контроль не файлы, а отдельные функции в коде.

Чёрт, чёрт побери! Это же то, что надо :D
dervish_candela: (Default)
Поддержка юникода в именах файлов. Я точно знаю, что у TortoiseSVN c этим не было никогда и никаких проблем. У распределенных наших любимцев с добавлением файлов в локали и латинице проблем нет, но и Hg, и Git отказываются инициировать директорию с иероглифами или добавлять в репу такие файлы. Жалкое, душераздирающее зрелище. Неужели код для работы с ФС нельзя было стырить из кодобазы SVN?

TortoiseSVN (только tortoise-gui, не включает клиент svn) и Базар (explorer, tortoise-gui, cmd) справились с этим, не моргнув глазом.

После этого все претензии на крутизну дизайна со стороны гита и меркуриала как-то бледнеют, если честно. Не поддерживать юникод было простительно 10 лет назад.

Почитал ихнюю вводную «why Bazaar». Много интересных сравнений с гитом и меркуриалом. Соблазнят, собака, соблазняет.

Насчет переименовок директорий как первоклассных объектов вопрос мутный, но тема правильная: ренеймить я действительно боюсь, ещё более я боюсь ренеймить в бранче (когда они у меня есть). и поддержка мержа в меркуриале, представляющая из себя нерабочий скрипт с вызовом kdiff3, меня совершенно не радует. После него подобное, например, зрелище, выжимает слезу:



В самом деле, гуй у него выглядит очень мощно. Лог весьма удобен, скорее напоминает интерфейс почтового оклиента в режиме треда (не считая дерева ревизий): гиперссылки, заголовок, поле с файлами. Хотя на дизайн окон в целом сильно повлияли линуксовые веяния, у TortoiseSVN дизайн окон более традиционный, близкий нашему сердцу виндовый. Очень качественная поддержка юникода - во всех ключевых местах мы увидим то, что ожидаем увидеть, а не ряд жалких вопросиков. Диффер поддерживает как локаль, так и юникод (хотя не умеет правильно сводить файлы в разных кодировках к одной).

Также интересен тем, что заявляет специальную поддержку традиционной, централизованной модели (с залочиванием файлов) - а в нашем деле эта модель была бы идеальной, т.к. текущая модель работы с бумажными чертежами полностью основана на уникальности главного бумажного оригинала. И, к сожалению, в текущей ситуации с бинарными файлами чертежей они являются наименьшей единицей для редактирования: просто подправить текст не выйдет, квант изменения - весь файл.
Ситуация с нужностью централизации в VCS, правда, пока вообще гипотетическая, т.к. сети мы не имеем, и любая модель попросту не будет работать ввиду того, что разработчики сидят за километр от конструкторов.

Но: ощутимо медленнее меркуриала.

В общем, я серьезно в сомнениях, что взять на следующий рабочий проект.
dervish_candela: (WTF)
попробовал git. неужели не могли его допилить под винду хотябы до уровня хг пд винду? неюзабельно.

алсо, линус, ты правда печатаешь каждый раз слова «status» и «сommit» целиком? где короткие команды - st, ci? зачем набирать точку в add - и так, что ли, непонятно, что я хочу сделать? странно.

меркуриал, даже при его глюках, удобнее. как минимум, сильно проще (поди догадайся, что перед коммитом в гите надо ещё файлы в очередной раз «добавить»). но гуй у Меркурия, конечно, никудышний. У тортойз-гита гуй слямзен целиком с тортойз-свн, что типа кул. Впрочем, ввиду специфики использования, гуй в хг мне нафиг не сдался, за исключением просмотра лога; для рутинных коммитов же cmd вполне хватает.

огомной разницы в производительности своем рабочем, на не самом новом (пень 4 2.4Ghz, 1 гиг памяти) компе я не заметил. Меркуриал, правда, большими (десятки мегабайт) файлами немножко давится, но не до потери функциональности. Видимо, принципиальные сравнения этих систем нужно проводить на безглючных версиях в родной среде (под линухом, то бишь). не знаю даже, стоит ли пробовать базар - гит хоть обещали что будет сумасшедше быстр.
dervish_candela: (Default)

ДВЕ ТЫСЯЧИ ДЕВЯТЫЙ ГОД. Люди до сих пор не умеют использовать юникод. Видимо, всё-таки легенда о вавилонском смешении языков имеет под собой какие-то рациональные основания. Есть, интересно, какой-нибудь неублюдочный диффер/мержер?..
UPD: KDiff3 не виноват. Виноваты ублюдочные скрипты в виндовском дистрибутиве Hg. Да, конечно, виндовская консоль - гавно, и всё такое, только вот у TortoiseSVN таких проблем нет, правда?
UPD2: И вообще, причем тут виндовская консоль? Просто кривые руки, ведь открывтаь-то файлы скрипт открывает. А вот имя результирующего файла при мерже на вход диферу явно передают через ж.
dervish_candela: (Default)
Современные технологии меня трогают до слез. ВНЕЗАПНО, кликнув на маахонький подозрительно знакомый значок во вкладке скрипта в IDE «Комодо», обнаруживаю что мне предлагают сделать Hg-коммит! Интеграци~я *_*
Алсо RxToolkit в комоде прекрасен. Лучший дебаггер регэкспов из всех, что я видел (2 шт.). До этого я работал в Kodos (тоже родной, на питоне), функционал тот же, но комод удобнее, красивее и шустрее. Как и во всём остальном что касается комода — «удобнее и красивее» не удивило. Но вот «шустрее» стало приятным сюрпризом :)

Открыл для себя синтаксис флагов (?...). Shiawase ~^_^~. Наконец-то я могу внедрить опции исполнения в регэксп, а не помнить сам, что их надо передать движку. Алсо to whom it may concern, я е..ался с re.UNICODE добрых часа три только чтобы выяснить, что включать его нельзя. Все прониклись? Включать re.UNICODE, обрабатывая файлы в utf-8, НЕЛЬЗЯ. Иначе ничего не будет работать. Самое смешное, что и Кодос, и RxToolkit вообще никак не реагируют на этот флаг (иначе я бы выяснил эту муть куда раньше, да). А стоит перепастить код в скрипт - и ни..уя не работает. Швайссе!

P.S. Буду делать свой первый pull/merge, пожелайте мне удачи :)

TortoiseHg

Jun. 11th, 2009 01:15 pm
dervish_candela: (Default)
Поставил, опробовал. И конечно же, забыл принести на работу :) Работает, вроде бы. Даже не конфликтует с TortoiseSVN. Ну, а про внешность приложений на Gtk под винду всё уже сказано до меня. Нам, конечно, скорее ехать чем шашечки, но чисто эстетически, диалоги TortoiseHg по сравнению с TortoiseSVN выглядят просто жалко :(

Ловлю себя на мысли, что в данном случае из консоли работать как-то концептуально проще =) Причем распределенка оказалась на порядок удобнее для казуального версирования (как инструмент повседневной компьютерной жизни). Ноль возни с хранилищами и РК. Скажем, рисую я что-нибудь. Обычно я сохраняю новые версии под новым именем в одну и ту же папку. Вместо этого можно просто набрать команды «hg init» и «hg add» в этой папке, и после каждого сохранения выполнять «hg commit». И всё! Абсолютно не надо думать, — где, что и зачем. Оно просто работает.

А вот для работы централизованная система по-крайней мере, не хуже. Хранилище лежит на отдельном диске, что сильно повышает надежность (РК и хранилище общаются друг с другом только через транзакции), а не болтаются в одной и той же папке, при этом коммит одновременно выполняет роль бэкапа :)

P.S. Есть таки одна штука, которая немножко мешает - это жесткая политика по лог мессаджам (не сохранишь мессадж - не получишь коммита). Надо или отключить, или посмотреть, как это сделано в Git.
dervish_candela: (Default)
Опробовал сабж. Его рекомендовал аж ipse Линус. То есть конечно он рекомендовал прежде всего свой Git, но я тогда решил подождать, пока не будет Tortoise-оболочки (интеграции в эксплорер) для него. Теперь он есть, и приходится признать, что я не хочу разбираться с Git по одной единственной причине - уж слишком у него идиотское название. В пользу меркуриала было и то, что написан он на расовом питоне.

Ну что сказать... нормальная система. Коммиты делать получается, команда add умная (так же как в bzr и git, для работы достаточно указать add или addremove без каких-либо параметров), экспорт предыдущей ревизии я с горем пополам нашел — работать можно. Ну, вот и работаю. Как честно откатить конкретный файл на раннюю ревизию, пока люто не понял. С распределенно-специфичными понятиями и терминами тоже пока разобрался не очень. То есть, как иметь все подразумевающиеся распределенные ништяки, я пока не в курсе. Острое чувство беспомощности прилагается в комплекте - великий виндовский шелл cmd.exe доставляет, да. Ни просмотреть лог, ни увидеть имена добавленных файлов, ни вбить паттерны в поиск...

А где же TortoiseHg, спрашиваем мы? А вот оно, отвечаем мы, открывая принесенную на работу пачку TortoiseHG-stable.zip. А там внутри - surprise! - лежит конструктор! «How To build TortoiseHg for Windows», simple guide в двадцати шагах. I love linux folks!
dervish_candela: (Default)
Да я бы, если честно, и QR-код с лог-месседжем поставил. Только тогда со мной точно придут поговорить сотрудники особого отдела (им же там ведь скучно очень).

Конструкторская разработка - это ведь почти такая же штука, как программирование. Каждый день добавляется или изменяе6тся что-то по мелочи, и даже не факт, что все изменения совместимы. Если программисты смогли рано или поздно себе написать хороших VCS, люди на производстве ведь до сих пор держат всё это в голове! (омайгад). У них нет ни VCS, ни тест съютов. И когда в меня тыкают прошлогодним чертежом с требованием немедленно сказать, почему вдруг там размер 42H6 вместо 42H8, I reach for my browning я начинаю ощетиниваться и шипеть. Потому что я точно помню, что это отверстие менялось с 42H8 на 42H6 и обратно как минимум пять раз, по требованиям/просьбе/рекомендациям абсолютно разных людей, иногда в один день.

Ну это о пользе VCS для меня как разработчика. Ревизию же нужно на чертежах проставлять затем, чтоб я мог сразу выхватить из рук тыкающих устаревшие версии и оперативно запилить их. Конечно, есть вещи, которые не мняются десятилетиями - такие многие у нас помнят наизусть. Но в экспериментальной разработке охватить взглядом содержимое чертежа и сказать, какая это из версий, никто из людей не в состоянии.
dervish_candela: (Default)
Но великодушно разрешил также Mercurial, написанную на расовом Питоне. Пробуем. Гит будем пробовать, когда появится TortoiseGit :)
dervish_candela: (Default)
http://www.youtube.com/watch?v=4XpnKHJAok8

They may not be literally disconnected, but in practice, they aren't really well connected either.
Even if it's not completely offline, it's important to be able to do everything you want to do from any location without having to be able to access a server.


И хотя Линус говорил о преимуществах распределённых SCM над централизованными, думаю, это хорошо выражает и суммирует моё недоверие к любым формам "веб-приложений". Их единственное назначение как я его вижу - это попытка стртегического перенаправления контроля (а значит, в итоге и денежного потока) из рук людей в руки корпораций. Никаких технологических преимуществ концепция веб-приложений не содержит, и любые проблемы, которые она якобы рещает, решаются более эффективно и надёжно традиционными средствами. А в вопросах обеспечения безопасности третья сторона (сервер: бэкап, CA, мёртвая рука итд) будет требоваться независимо от технологической парадигмы.

Это в продолжение дискуссии с некоторыми людьми об этих новомодных глупостях. Разница между теоретическим «not disconnected» и практической инженерной оценкой «not well connected» хорошо иллюстрирует мертворожденность подобных штук. Не говоря уж о невозможности обосновать необходимость их использования, — пока сеть не станет действительно жёсткой системой, работоспособность любых таких вещей не гарантирована, на них нельзя положиться, а значит — их использование требует принятия идеологии смирения и беспомощности.

А жесткой системой сеть станет не раньше, чем у нас наступит полный blame.
dervish_candela: (Default)
Кто нибудь пользовался Меркуриалом или Базаром?

April 2017

S M T W T F S
       1
234 5678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 09:22 am
Powered by Dreamwidth Studios