Mercurial против Git в Facebook

Я не писал что она не нужна, хватит перевирать мои слова.

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

Хорошо, нужна.

А с изменениями то что делать? Особенно, если они в одном файле, но их нужно разделить?

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

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

очереди подставлять снапшоты в рабочую копию. Но по-моему это редкая ситуация.

Не выйдет, если доступ к репозитория только на чтение.

Дата вообще не важна, я единичный патч могу отправить почтой и внесут его в репу неделей позже и в случае svn.

Рефлоги вообще человека со стороны интересовать не должны.

Не выйдет, если доступ к репозитория только на чтение.

Если он только на чтение то зачем ты коммиты готовишь?

Дата вообще не важна, я единичный патч могу отправить почтой и внесут его в репу неделей позже и в случае svn.

Дата когда ты его кодил и отправлял - не важна. А вот дата внесения его в репу как раз важна. И гит именно её почти не поддерживает.

Рефлоги вообще человека со стороны интересовать не должны.

Как это не должны, если в них хранится как раз нужная история а не мешанина из сфабрикованных коммитов.

Если он только на чтение то зачем ты коммиты готовишь?

Это называется opensource

в них хранится как раз нужная история

Нет

Ты вообще не понял, что делает bisect, похоже.

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

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

В свн же всё проще: допустим, у тебя есть ревизия 1000 без бага и ревизия 1100 с багом, ты безо всяких костылей обновляешься до 1050, проверяешь, затем до 1025 или 1075 итд.

В свн же всё проще: допустим, у тебя есть ревизия 1000 без бага и ревизия 1100 с багом, ты безо всяких костылей обновляешься до 1050, проверяешь, затем до 1025 или 1075 итд.

Без подключения к серверу?

С подключением, разумеется.

С подключением, разумеется.

Вот именно. А теперь процитирую тебя же:

Затем, что Werenter заявил, что в свн без доступа к серверу чуть ли не блокируется вся работа. Это неверно и я ему возразил.

Так это не «вся работа» а редкий случай поиска бага задним числом.

Так это не «вся работа» а редкий случай поиска бага задним числом.

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

Номера коммитов тут вообще не причём. Важен простой и удобный интерфейс, в том числе не требующий подключения к серверу.

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

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

Это потому что ты не осилил git и git-bisect. Когда баг ваще непонятный ни разу, но воспроизводится на раз-два, проще найти изменение, которое его внесло. Особенно актуально в сишечке с её анал-карнавалом из UB.

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

Когда баг ваще непонятный ни разу, но воспроизводится на раз-два

Вот это что-то плохо совместимое. Я ж говорю - редкая ситуация.

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

И вас тоже поздравляем!

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

Хеши тут вообще ни при чем. С помощью bisect ты помечаешь какие у тебя коммиты «хорошие», а какие - «плохие». А потом git обходит кусок графа между коммитами и предлагает тебе попробовать скомпилировать проект на том или ином коммите. То есть, по сути, при bisect граф раскручивается в линейную историю (хотя это и выглядит как прыжки туда-сюда по истории). Да, это можно было бы сделать и руками (если отследить всю цепочку merge'ей и если в истории нет какого-нибудь ада, типа «octopus merge»), но вот номера коммитов не помогли бы при нелинейной истории (в SVN такое вроде как редко: я работал только на одном проекте, где был SVN и там не было ветвления; по отзывам, в других местах было примерно также).

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

А если баг воспроизводится только в проде

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

А если про локальный софт, то всё ещё проще.

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

Ага, и лог всего трафика на многогигабитном линке с момента старта демона? Ведь баг может зависеть от таймингов приёма-передачи.

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

Ага, и лог всего трафика на многогигабитном линке с момента старта демона? Ведь баг может зависеть от таймингов приёма-передачи.

Почему нет? Добавляешь кольцевой буфер и дампаешь его при срабатывании вотчдога.

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

Да, это можно было бы сделать и руками (если отследить всю цепочку merge'ей и если в истории нет какого-нибудь ада, типа «octopus merge»), но вот номера коммитов не помогли бы при нелинейной истории (в SVN такое вроде как редко: я работал только на одном проекте, где был SVN и там не было ветвления; по отзывам, в других местах было примерно также).

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

Кольцевой не позволит воспроизвести всё, надо линейный со старта тогда. Для гигабитного линка за неделю это будет уже 60ТБ например.

Для гигабитного линка за неделю это будет уже 60ТБ например.

Херня вопрос. Это два SSD.

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

Вот только в SVN свой набор проблем, типа возможности случайно перезатереть чужой коммит/файл, т.к. вся команда сидит на одной ветке, а задачи могут затрагивать одни и те же файлы (мы с этим сталкивались, было неприятно).

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

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