Какой (D)VCS Вы пользуетесь?

Можно подробнее? ... . Я имел в виду простоту и разумность интерфейса...

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

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

Хороший пример этой мешанины виден на {mq, rebase, histedit} - все делают примерно rebase, но с разными настройками выкинутыми пользователю и через различные кишки. Или существует несколько костылей для реализации staging area. Все варианты последнего, например, требуют бОльшей работы руками. MQ, например, вообще подумывают выкинуть, хотя без него будет очень трудно распиливать коммиты.

В git же не нужно набирать стандартные фичи включением расширений, все пользователи имеют сразу весь функционал из коробки и все операции, от простых до продвинутых, имеют одну модель - через цепочки коммитов и ссылки на их вершины. Git решает сложные задачи просто в отличие от hg.

Кроме проблем с модульностью в hg занесли и другие неудачные архитектурные решения. Например, в mercurial отслеживаются, как и в svn, файлы вместо данных - т.е. нельзя (всё ещё?) без последствий для истории удалить и добавить файл под другим именем, а таких понятий как перемещение кусков кода между файлами для { diff, annotate и т.д. } в hg вообще не существует.

Я никогда не понимал, зачем в гите staging area ... с моей точки зрения, это костыль, который используют за неимением лучшей системы.

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

А для коррекции конкретных патчей редактировать историю?

В VCS не существует патчей самих по себе, все они являются частью истории изменений независимо от технического способа их размещения.

Дизайн Monotone, ты хотел сказать.

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

Стек патчей - это стиль работы, изобретенный задолго до git и mercurial, и реализованный в, например, quilt.

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

Бэкапы на DVCS настолько же целостны, насколько целостен репозиторий DVCS. Репозиторий на криптохешах (OpenCM, далее везде) целостен автоматически,

DVCS не обязана быть на криптохешах.

В mercurial нет staging? Как в нём жить?

В mercurial нет staging? Как в нём жить?

Прикостылить 10 разных решений через расширения.

А в чем разница между коррекцией патчей и редактированием истории?

Дизайн Monotone, ты хотел сказать.

Что хотел, то и сказал.

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

в hg калька на это добро оказалось по причине закостыливания отсутствующего функционала.

Не знаю, какого именно автора ты имеешь в виду, но один из них напрямую лгал. Твоя фраза тоже похожа на ложь.

DVCS не обязана быть на криптохешах.

Знаю. Поэтому и не сказал, что обязана.

Потому что нормальные люди для этого ветками пользуются

Для чего «этого»?

Для хранения цепочек локальных патчей.

Я говорил о разработки одной цепочки. Правильно ли я понял, что для разработки одной линейной цепочки патчей «нормальные люди» используют несколько веток? Тогда расскажи об это подробнее.

То есть наличие mq, rebase и histedit в hg — это следствие плохого дизайна; а наличие rebase, stash, stgit, guilt в git — это продуманный дизайн во всей красе?

Ну и про «глупо внедрённая модульная архитектура» доставило отдельно.

stgit, guilt в git

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

Понял. // добавляет комментарий

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

Правильно ли я понял, что для разработки одной линейной цепочки патчей «нормальные люди» используют несколько веток?

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

Правильно ли я понял, что для разработки одной линейной цепочки патчей «нормальные люди» используют несколько веток?

Одна ветка и rebase, ничего более

А, так ты не знаешь, что серия патчей mq - это ветка... Окей, и чем же, по-твоему, ветка git отличается от серии патчей mq? Ну, кроме того, что быстрого и простого способа вернуться к предыдущему патчу не существует.

Например, в mercurial отслеживаются, как и в svn, файлы вместо данных - т.е. нельзя (всё ещё?) без последствий для истории удалить и добавить файл под другим именем, а таких понятий как перемещение кусков кода между файлами для { diff, annotate и т.д. } в hg вообще не существует.

Гиту кстати сносит крышу в сложных ситуациях, особенно когда файл А переименовали в Б, а файл В переименовали в А, и ты пытаешься проследить изменения в Б или А, или черри-пикнуть патч со старой ветки до переименований в новую

Окей, и чем же, по-твоему, ветка git отличается от серии патчей mq?

Нет лишних сущностей с отдельной системой команд

Ну, кроме того, что быстрого и простого способа вернуться к предыдущему патчу не существует.

Бугага

и чем же, по-твоему, ветка git отличается от серии патчей mq?

Нет лишних сущностей с отдельной системой команд

И почему это хорошо?

Бугага

Веско и характерно.

И почему это хорошо?

Потому что проще

Веско и характерно.

А что еще можно ответить на ерунду?

И почему это хорошо?

Потому что проще

Ну, я не стану напоминать тебе рассуждения Линуса о porcelain и plumbing - ты о них просто не знаешь.

А что еще можно ответить на ерунду?

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

git checkout HEAD^

рассуждения Линуса о porcelain и plumbing

Причем это здесь? plumbing приходится использовтаь только для совсем уж извратных вещей

Это не аналог. После внесения изменения и коммита тебе понадобится rebase.

Нет лишних сущностей с отдельной системой команд

рассуждения Линуса о porcelain и plumbing

Причем это здесь?

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

Команды для работы с ветками (log, checkout, rebase, merge, branch, commit - больше ничего в посведневной работе не нужно) являются типичными porcelain-командами, так что не в кассу

Команды для работы с ветками (log, checkout, rebase, merge, branch, commit - больше ничего в посведневной работе не нужно) являются типичными porcelain-командами, так что не в кассу

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

А для коррекции конкретных патчей редактировать историю? [Это был nezamudich, но вставил для контекста.]

А, так ты не знаешь, что серия патчей mq - это ветка... Окей, и чем же, по-твоему, ветка git отличается от серии патчей mq? Ну, кроме того, что быстрого и простого способа вернуться к предыдущему патчу не существует.

и чем же, по-твоему, ветка git отличается от серии патчей mq?

Нет лишних сущностей с отдельной системой команд

И почему это хорошо?

Я, как сторонник hg, в некоторой степени всё же согласен тут с annulen. Я не использовал MQ; я считаю, что нужно «для коррекции конкретных патчей редактировать историю»; и Mercurial люблю как раз за то, что, на мой субъективный взгляд, там это делать, в частности «возвращаться к предыдущему коммиту», даже без MQ, легче (в не смысле количества телодвижений, а в смысле их логичности/очевидности), чем в гит — а после разделения private/draft/public ещё и безопаснее.
Я использую безымянные ветки и bookmark'и (а не named branch'и и MQ). И я против лишних сущностей (типа MQ).

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

Приведите, пожалуйста, какой-то пример использования staging.

Скажу честно, я Вас не понимаю, как говорят, от слова совсем.

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

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

«Хороший пример этой мешанины виден на {mq, rebase, histedit}» — не спорю, в редактировании истории (фича, которая AFAIK в изначальном hg вообще считалась чем-то плохим, хоть я с этим не согласен) пока мешанина. Но зато нету нелогичностей в более базовом функционале (commit/update/push/pull/outgoing/incoming) — в отличие от гит. Staging area, как я уже говорил, не нужна, это костыль, пытающийся решить проблему отсутствия удобного инструмента созданием лишней сущности (ведь «закоммитить не все изменения из рабочей копии» — это по сути быстрая операция (2 мин), не требующая каких-то промежуточных состояний; ну, тулза, которая делает эту операцию, может использовать какие-то свои временные файлы, но это именно временные файлы, а не значимая вещь, которая должна храниться в БД).

«а таких понятий как перемещение кусков кода между файлами для { diff, annotate и т.д. } в hg вообще не существует.» Согласен. Но думаю, со временем исправят. Тут штука какая: git (AFAIK) не позволяет вручную вносить информацию об отношении между файлами N-й ревизии и файлами (N+1)-й ревизии — зато умеет вычислять её сам; mercurial (хоть и куцо) позволяет — зато не умеет вычислять её сам (я имею в виду, опосля, уже после создания коммита). Никто не мешает Mercurial'у со временем научиться (а в идеале должны быть оба механизма). (Хотя, скажу честно, тут я могу ошибаться, потому что я не уверен до конца, как тут сделано в гите.)

«SA даёт очень удобный пользовательский интерфейс» — про это уже писал. SA — это костыль, который создан исключительно потому, что механизм редактирования непоследней точки в дереве коммитов (т.е. не рабочей копии, а сделанных коммитов) ещё недостаточно удобен, не существует пока достаточно удобного механизма перекидывания части изменений из N-го в (N±1)-й коммит и т.п. А так, в теории: достаточно лишь дерева коммитов и рабочей копии, которая тоже является нодой в дереве версий (виртуальной, нефиксированной).
https://raw.githubusercontent.com/sasha2048/test/master/untitled1.png
Я, когда делал первые приложения для работы с БД, тоже делал эту ошибку: путал временные данные редактора и сущность, которая является частью бизнес-логики. Допустим, есть достаточно сложный диалог для добавления какой-то сущности (заказа, договора, товара, пофиг). При нажатии «ОК» в БД создаётся одна или несколько записей в БД. Но до нажатия кнопки «ОК» в БД не должны создаваться основные записи; могут временно создаваться какие-то временные (допустим, автосохранение данных формы на случай если в процессе заполнения формы браузер юзера крэшнулся) — но они совсем другого порядка (они являются частью view, а не бизнес-логики). Даже если форма не AJAX и её заполнение состоит из отсылки многих HTML-форм (например, добавить пункт в договор, добавить подпункт к пункту) — результаты которых технически необходимо где-то временно хранить на сервере — всё равно, заполнение подформы не должно провоцировать появления основных записей в БД. Потому что view — это view, а model — это model (даже если по каким-то причинам: отсутствие AJAX, крашащиеся браузеры — приходится временно хранить данные view на стороне сервера).
Так вот, дерево коммитов (и виртуальная точка рабочей копии в нём) — это существенные части. Я допускаю, что диалог создания нового коммита (или диалог перенесения изменений между двумя последовательными коммитами, или другой) (под «диалогом» я подразумеваю, естественно, не только GUI-диалог, а в широком смысле, любой, в т.ч., например, последовательность консольных команд, которые в итоге приводят в выполнению одной логической операции) может хранить где-то временные данные. Но staging area — это именно что временные данные, которые нужны только в течение пары минут от начала процесса создания нового коммита до собственно создания коммита (в отличие от файлов в рабочей копии и коммитов в дереве версий) и давайте не путать существенное и временные данные, засоряя этим логику и модель БД.

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

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

Вот таким шаманством это решалось в своё время:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch 'путь_к_каталогу/файлу'" HEAD
git reflog expire --all
git gc --prune

Если очень хочется то можно удалить насильно из истории целиком

Изменение опубликованной истории это вообще не вариант

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

Team Foundation Server

git

некоторой степени всё же согласен тут с annulen

Согласен в чем? Он наговорил много.

Согласен в чем? Он наговорил много.

что для коррекции конкретных патчей редактировать историю
что лишние сущности не нужны (MQ в идеале лишний)

Согласен в чем?

что для коррекции конкретных патчей редактировать историю

Такое впечатление, что ты не закончил фразу.

что лишние сущности не нужны (MQ в идеале лишний)

Она лишняя _почему_? MQ реализует определенный workflow и станет лишним только тогда, когда что-то реализует этот workflow лучше. Changeset evolution этого пока не делает.

Такое впечатление, что ты не закончил фразу

лень было набирать, уже нанабирался
т.е. Вы мою мысль поняли (несмотря на несогл. предл.)? или ждёте продолжения?

Она лишняя _почему_?

потому что идеальная СКВ в моей голове содержит только дерево коммитов и рабочую копию (также позволяет цеплять к их элементам свойства) и позволяет делать с ними все возможные операции
хотя я не спорю, что в реальности возможности Mercurial по редактированию истории (в частности secret-коммитов) не настолько широки/удобны, и некоторые вещи, возможно, пока проще делать через MQ

т.е. Вы мою мысль поняли (несмотря на несогл. предл.)?

Нет.

потому что идеальная СКВ в моей голове

В твоей.

Нет.

что теоретически идеальным путём для подготовки серии патчей является закоммитить их в виде secret-коммитов и редактировать историю

В твоей.

ага

что теоретически идеальным путём для подготовки серии патчей является закоммитить их в виде secret-коммитов и редактировать историю

mq это и делает. Коммиты, правда, draft (ЕМНИП).

Before we begin this tutorial, there are 3 things to keep track of when using the mq extension: the localRepository, the mqPatches, and the workingDirectory.

mqPatches — лишнее. И, вообще, весь их workflow «неправильный».
(Хотя я понимаю, что кто-то этим пользуется и кому-то помогает. Я не говорю «СРОЧНО УБИРАЙТЕ!!!». Но в целом я за логическую чистоту.)

mqPatches — лишнее

весь их workflow «неправильный».

Я даже не стану спрашивать, почему. Ты опять начнешь говорить о чем-то, что существует в твоей голове.

Когда набиваешь сообщение на LORe, то, если будешь внимательным, обнаружишь снизу ссылку описание разметки LORCODE, там есть замечательный тег quote для цитирования. В некоторых местах ты им пользуешься, а сейчас какое-то мясо - что с тобой не так ... приступы что ли какие?

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

Есть некая абстрактная идея модульности, а есть её конкретные применения и я уже ниже много текста написал что тут не так в случае с hg. Но если совсем не понятно в техническом изложении, то вот последняя моя попытка, на этот раз сказка про hg ls ...

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

Посмотрели на своё поделие овощи и отчаялсиь - модули то вроде придумали, но ни одного модуля в проекте не оказалось. Чтобы все могли прочувствовать прямо «из коробки» какие они альтернативные и шагают в ногу со временем, решили вынести и весь прочий функционал в модули - так первыми модулями стали цветовая подсветка и чтение настроек из переменных окружения. И чтобы гениальное архитектурное решение совсем не могло ускользнуть от глаз пользоватея сделали конфиг /etc/ls/ls.conf в котором нужно каждый модуль включать явно.

* Модули, как выяснилось, не есть плохо, но хорошо ли их засовывать куда попало?

Прошло время и новой реализацией стали пользоваться другие персонажи, а после некоторые из них реализовали поддержку других объектов fs, но все они обладали некоторыми недостатками. Например, было два модуля для поддержки директорий, но один из них не умел выводить владельца директории ибо автору не было это нужно, а другой отображал дату модификации в каком-то странном формате мало понятным остальным.

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

* Так что же делать нашим овощам? Забрать в ядро ни одну из реализаций поддеркжи директорий нельзя ... наверное, нужно подождать лет 10 пока не появятся другие реализации, более конкурентноспособные.

... а не первое попавшееся (как в некоторых случаях в гите)

А в git есть общий консистентный дизайн всех фич который постепенно реализовывался и развивается сейчас. Пока разработчики hg ждали у моря погоды в git давно всё основное запилили и mercurial уже много лет люто отстаёт по функционалу. Питонячий проект за десять лет не смог догнать по прямому функционалу в настоящим сишную VCS - это настоящий эпик фейл.

... в редактировании истории ... пока мешанина ... перемещение кусков кода ... думаю, со временем исправят.

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

Staging area, как я уже говорил, не нужна, это костыль, пытающийся решить проблему отсутствия удобного инструмента...

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

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

Это состояние почти что патч с изменениями и staging area как раз такое состояние представляет в удобном для VCS виде - оно есть «временный» файл и всё такое. Никакого принципально иного средства редактирования изменений не существует.

А что за Phabricator? Типа замена Jira/Youtrack?

Типа комбайн типа GitLab'а.

На работе git и mercurial. Для своих задачей - git.

 что именно вы иллюстрируете?

тот факт, что в пользователя git с порога летит жаргон, вне git бесполезный.

то что я выбрал git не потому что он мне подходит а из-за понтов?

А вы разве тоже да? :)

Не люблю хелпы в духе Капитана Очевидность.

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

Как так?

Совершенно точные и столь же бесполезная для решения реальных проблем справка. Хорошо хоть stackoverflow есть.

ощущение «илитарности» его пользователей

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

в git реализовано сторонними инструментами

в hg реализовано искаробочным плагином mq

Смекаете?

с git'овской колокольни, кажется лишней сущностью.

у гитопользователей вместо этого guidelines «не делайте так» http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

в git реализовано сторонними инструментами

ШТА?

В git оно реализовано самым стандартным инструментом - коммитом.

очередь патчей, не снапшотов, реализована в гите исключительно сторонними инструментами: gitUM, stgit и т.п.