Mercurial против Git в Facebook

Это работает только для header-only кода и рано или поздно «выстреливает». А вообще такое запрещено гайдами разработки.

предлагаю намеренно терять информацию о разработке фичабранча

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

Причёсанная ветка нужна. Только её не надо никак хранить - она попадает в виде такого же набора коммитов в транк. Помойковетка не нужна ни в каком виде.

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

Ну ок, пусть пушнет свои помойковетки перед уходом, этого никто не запрещает. На них посмотрят, доделают и потрут.

Всмысле «пусть пушнет»? Это ему надо? Или компании надо вступать с ним в разборки касательно его обязательств при уходе? Проще просто хранить, это почти бесплатно.

А если он там реально занимался нужным рефакторингом, то в результате будут коммиты связанные с рефакторингом. Больше ничего не нужно.

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

Ты так и не объяснил, как изменения в текстовом редакторе IDE могут её ломать.

Судя по обрывкам бреда, его ide регулярно синхронизирует код в локальный staging. Сама, по факту записи или хз чему еще.

Кажется начинаю догадываться.

Все ide и редакторы, которыми я пользовался отслеживали изменения открытых файлов и уведомляли, что они изменились, спрашивали «что им делать: обновить или нет».

Он же зачем-то настроил себе авто сохранение при потере фокуса.

В любом случае это упорин.

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

Не надо работать в таких местпх. Разбивка на коммиты нужна для удобства ревью и истории, а не для удовлетворения чужой паранойи.

Года до 2012 в Facebook царствовал Git, но с ним были проблемы. У лицекниги была жирная монорепа, и Git начинал ощутимо лагать на ней. Перцы из Facebook написали разрабам гита с предложением ускорить работу собственно гита, но те их послали, предложив место этого распилить монорепу на кусочки. Лицекниговые такой поворот сюжета не оценили, и тут им подвернулся Mercurial, разрабы которого как раз без проблем приняли патчи с улучшением производительности

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

Разбивка на коммиты

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

С чего это превращается? Разумеется название ветки тоже надо включать в версию.

Зачем кому-то в истории видеть

Foo
Bar
Fix this shit
WIP
WIP
Try another algo
Simplify
WIP
WIP

Кому и чем это поможет?

Кому-то чем-то когда-то. Заранее нельзя сказать. Все логи хранятся именно на всякий случай - а вдруг потом пригодится. Я вот иногда смотрю логи в /var/log больше чем годовой давности, но конечно заранее я это предусмотреть это не мог. Проще просто хранить, особенно если это не затратно. Разумеется в логе должны быть не только названия но и диффы.

Кому-то чем-то когда-то. Заранее нельзя сказать. Все логи хранятся именно на всякий случай - а вдруг потом пригодится.

Это шизофрения – проводить ревью этой лапши отказываются все вменяемые мейнтейнеры.

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

Какие в жопу логи? Мы про коммиты говорим.

Это шизофрения – проводить ревью этой лапши отказываются все вменяемые мейнтейнеры.

Причём тут ревью? Я не предлагал менять никакие процессы от того как ты их считаешь. В релиз идёт сборный коммит с понятным комментарием и ревью делается по нему. А это - логи. Ты понимаешь что такое лог?

Какие в жопу логи? Мы про коммиты говорим.

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

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

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

Причём тут ревью? Я не предлагал менять никакие процессы от того как ты их считаешь. В релиз идёт сборный коммит с понятным комментарием и ревью делается по нему. А это - логи. Ты понимаешь что такое лог?

Я не понимаю что такое логи в контексте коммитов Git. Есть дискуссии, есть фиксы того что просили ревьюверы. Логов нет.

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

На кой хрен оно надо-то? Все дискуссии зафиксированы в обсуждении, вот тебе логи.

Я не понимаю что такое логи в контексте коммитов Git. Есть дискуссии, есть фиксы того что просили ревьюверы. Логов нет.

Ещё раз: ты обсуждаешь организацию процесса разработки, а я обсуждаю логи. Логи - это не часть процесса, а метаданные к нему, это журнал того кто что делал в какой момент времени. Для собственно разработки они в норме не нужны, но во всяких непредвиденных ситуациях могут пригодиться.

Логов нет.

Ну конечно у тебя их нет, если ты их трёшь.

Для собственно разработки они в норме не нужны, но во всяких непредвиденных ситуациях могут пригодиться.

Ты не тех людей кто дома склады говна устраивает? Давай сразу кейлоггер в ide воткнем, чего мелочиться.

То, что веб-сервер современного сайта вместо «юзер посмотрел такую-то страницу» создаёт больше десятка длинных строк в логе с детализацией своего общения с браузером - тебя не смущает?

дома склады

Склад дома занимает место. А логи разработки, по современным меркам, не занимают. Так что их можно забесплатно хранить сотнями лет и нет причин удалять.

кейлоггер в ide

Неудобно по куче причин. А вот cow-файловую систему с вечным хранением может и имеет смысл. Мне как раз недавно подсказали NILFS2.

То, что веб-сервер современного сайта вместо «юзер посмотрел такую-то страницу» создаёт больше десятка длинных строк в логе с детализацией своего общения с браузером - тебя не смущает?

Конечно нет. Логи вебсервера полезные, «логи git» это бесполезный мусор.

А вот cow-файловую систему с вечным хранением может и имеет смысл. Мне как раз недавно подсказали NILFS2.

Засунь в блокчейн.

Со стороны глядя, нет ничего странного. Большинство в треде – это git-фанбои, поэтому нормально, что у вас всё ОК с git. Но вы продолжайте, еды на форуме много не бывает :D.

Да при чём тут фанбойство?

Я бы сказал, что большинство на ЛОРе - это пациенты, по которым плачет Кащенко.

Особенно, это товарищ Брежнев, которому всегда всё не так, кроме CVS и мерзкой жабы. При этом, у него всё является «античеловеческими происками бесчеловечных капиталистов», но абсолютно не смущает тот фат, что отвратительная Жаба создавалась для упрощения эксплуатации человеко-винтиков, о чём открыто писалось во всех рекламных материалах жабы, как минимум до начала 2000-х.

Ну а что лучше Git-то, на самом деле? Только не надо начинать по новому кругу, что заплесневелые костыли типа SVN, что совершенно очевидно (по текстам комментов) пишут те, кто не смог осилить Git на минимальном уровне, хотя это по силе даже хомячку с IQ 80.

Ну так то хомячки < 80 IQ без напряга с помощью нейронки дипломы пишут. Комиссия >> 80 IQ эти дипломы положительно оценивают. Ты о чём вообще?

У Git есть недостатки. Более того, недостатки есть у совершенно любой системы контроля версий. Более того, у большинства VCS недостатки очень похожие, т.к. львиная их доля от того, что они манипулируют текстом программ как последовательностью байтов, и формат изменений тоже является последовательнастями байтов. Из-за этого, например, конфликты приходится решать в любой VCS, и они в любой VCS одинаково неприятны.

Но тут приходит Брежнев и начинает нести какую-то дикую ахинею из-за того, что он использует какой-то специальный редактор для специально одарённых людей, который всё делает не так, как редакторы для обычных людей. Какой-то ускоспециализированный редактор для редактирования корпроративного жабокода и сохранения в корпоративный CVS.

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

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

А мне понравилось. Несколько запятых пропущено, но всё равно сразу видно, что русский язык человек… понимает.

Я когда-то в начале века работал с svn. Оно через раз теряло изменения, если над одним файлом работало больше 2х человек в одно и тоже время. В git с этим попроще и вроде потери коммитов не наблюдается. Распределенность она такая, невидимая, но очень важная.

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

Да все просто. Лочить файлы на рид-онли или куски файлов, если заранее известна область работ, в бранче. Уведомлять кто залочил и договаривайся потом с ним ртом, а не мерж-конфликтами.

Мне нравится mercirial из-за tortoisehg, но с git у меня тоже проблем нет, хотя такой же лёгкой и удобной графической утилиты как thg я не нашёл - в основном использую lazygit вперемешку с cli напрямую.

С созданием одного патча для svn репозитория тоже проблем нет.

А помимо facebook используют mecurial: headgewars, octave, eric ide, graphicmagick, PyPy, RhodeCode, sudo.

Может он неделями свою ветку держит без слияний с быстрорастущей. А то он постоянно тысячи файлов упоминает.

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

trunk based development + инкрементальная разработка (коммитить часто и маленькими патчами).

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

Но я так понимаю, что Брежнев в одиночку пишет проект «Hello_world.java».

В реальной жизни всё случается, и на все случаи жизни такую простую соломку не подстелешь.

в этом была реальная производственная необходимость.

Интересно какая?

В начале века это получается когда свн только-только появился? Ну может баги какие были. 15 лет назад он уже полностью стабильно работал.

В git с этим попроще и вроде потери коммитов не наблюдается.

Гит ты тоже в начале века проверял?

Распределенность она такая, невидимая, но очень важная.

Причём тут распределённость? Мне кажется ты вообще не понимаешь что это в контексте гита, раз приплёл её сюда.

Что за ужасный костыль? git status показывает список нерезолвленных конфликтов, даже я это знаю хотя гит не люблю. Вот они гит-юзеры, даже в своём инструменте разобраться не могут.

В свн по номеру ревизии узнать ветку никаких проблем не составляет, но да, если он без указания ветки - неудобно, т.к. его суть в том чтобы видеть ситуацию не обращаясь к vcs.

ты как бы и прав и нет. нет никакого устойчивого образа процедуры резолюции конфликта, проводимого внешними к vcs средствами. то есть нет такого ПО, нет формата, протокола передачи, нет стандарта, который можно было бы реализовать. есть только предположение, что резолюция производится мелдом или обычным редактором. поэтому вместо передачи конфликта куда-то для его резолюции, он просто размещается в working copy.

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

в какой-то альтернативной реальности вся необходимая информация будет сериализована в какие-то структуры (а не плоские файлы), передана куда-то вовне по какому-то протоколу (а не записана в working copy), и вызван будет не mergetool а какое-то другое ПО.

возможно есть vcs, которая сама всё это содержит или как как-то иначе рашает проблему и при ее использовании вообще не бывает этого особого состояния working copy. но мне о такой не известно.

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

Дежавю. Снова тема про git, снова в ней Syncro, всё это уже было =)

Пора переходить на самоцитирование:

Критики git примерно так же разбираются в git, как критики systemd - в systemd.

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

правда есть одно но: может случиться, повсеместная замена гиту, если такое произойдет, опять будет выбрана через хайп, клиповыми карго-культистскими хомяками. а еще она может оказаться хуже: например, не быть логически корректной, путать и портить файлы, или например будет привязана к интернету

поэтому, не надо, пусть лучше сраный гит остается

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

Там может в тех патчах они переписали некоторые модули на Си :)

Конечно это спекуляция, но вполне может быть.

Справедливости ради, отдельные модули на Си там действительно есть. Но сути это не меняет.

вроде же джва раза уже объяснял как должно быть:

1. надо предварительно проверить будут ли конфликты и другие ошибки или выполнить сначала мерж в песочнице и если он завалился написать ошибку и оставить все как было. В 95% случаев разваленная рабочая копия мне не нужна. Если надо куда-то выгрузить всю кровь-кишки это можно делать при передаче флага –force.

2. кровь-кишки можно разложить по файлам с суффиксным форматом, например MySuperCode.java.${short_hash}.conflict. Мне кажется, какие-то другие системы управления версиями типа меркуриала или базара так и делали. Вот по ним пускай мержилки и работают.

гит убог потому что Лайнус писал мержилку под себя, там сначала, кажется, даже не было бранчей и их потом приделали как-то сбоку и вот все остальное делается наворачиванием костылей и хранится в одном бинарнике. Лайнусу вобщем-то ничего не надо было восновном кроме возможности принять патч и смержить, он об этом так и написал в своей книжечке. Ему удобнее что-бы мержилка сразу насрала под редактор если что не так. Ему может быть даже не надо канпелять, запускать и тестировать это все, потому что дядя Мортон все уже сделал в своем локальном репе. Он не работает на почасовке(и вообще не торопится) и его не пытаются постоянно выставить виноватым и продать другим работорговцам. Поскольку Лайнус был уже не молод его мержилка в отличии от эмулятора терминала выросшего в ядро ОС так и осталось убогой мержилкой, но этим приглянулась любителям казуальных технологий, которые ее везде продвинули пользуясь тем что свн по хттп не вывозил не говоря уже про прочие «аналоги».

гит гораздо чаще разламывает рабочую копию и чудит, хотя если другие тоже разламывают это не значит, что гит делает что-то хорошее

И?

Рабочая копия для этого и нужна, чтобы в ней работать.

Если в ней случился мусор, просто откатываешь состояние на последний коммит и начинаешь заново. В ней и не должно лежать ничего важного.

Если в ней случился мусор, просто откатываешь состояние на последний коммит и начинаешь заново. В ней и не должно лежать ничего важного.

чем это лучше пакования в бекап-архив? его ведь можно даже одной командой завернуть и двумя развернуть вместо пяти

а мержить kdiff’ом, он файлы не портит. Я, кстати, несколько раз так и выкручивался.

вам мержом приехал чей-то рефакторинг на тысячу строк кода

чей-то.

чей же?

приехал.

сам приехал?

рефакторинг на тысячу строк кода

это вообще без комментариев.

Как называется ваша контора, чтобы туда не попадать?

могу сказать, что проект бы на реакте, и там рефакторинги на тысячи строк были регулярной темой, при том что код оставался у бичным, меня там таки выставили виноватым и попросили уйти по собственному. За год на том проекте поменялось около 100% участников, из них 4 специалиста сразу не смогли работать с реактом и покинули проект через 1-2 месяца попыток.

Я не знаю как комментировать эту шизофрению.

Я вспомнил, что он эту же чушь нёс в предыдущем разговоре. У него там еще и на прод вкатывался код прямо с рабочей копии.

У него там еще и на прод вкатывался код прямо с рабочей копии.

это где такое было сказано?

Ладно, про прод там не было.

Пал последний оплот Mercurial (hg) (комментарий)

компиляция проекта на рякте занимала несколько минут(выжирая все доступные ресурсы ПК), без локального сервера который мониторит изменения и инкрементально пересобирает тупскрип в бандлы с таким работать было бы невозможно даже теоретически