инструменты для облагораживания репы в меркуриале

Для большинства задач готовых инструментов нет, но, наверное, всё это можно набыдлить через hg convert.

тут даже хочется именно систему, типа как для работы с файлами достаточно mkdir, rm, mv, cp, ln (и replace/awk/perl для ковыряния содержимого) — и ты типа все умеешь, так и тут

что касается hg convert — я не вижу в списке форматов «набор директорий, соответствующих коммитам с файлами метаданных»; ты предлагаешь конвертировать из меркуриала в меркуриал?

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

тут даже хочется именно систему типа как для работы с файлами достаточно mkdir, rm, mv, cp, ln

Да не вопрос - hg cp, hg mv, hg rm. Вопрос в том, как поверх результата применения этих команд (отредактированного ченджсета) накатывать уже имеющиеся ченджсеты. В принципе, можно через evolve или даже rebase, но будет много ручного труда.

ты предлагаешь конвертировать из меркуриала в меркуриал?

Естественно. Это вообще штатный способ преобразования репозитория.

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

Посмотри https://www.mercurial-scm.org/wiki/EvolveExtension Наверное, к нему можно свести всё, что ты хочешь, но мышетыкательного интерфейса нет.

Да не вопрос - hg cp, hg mv, hg rm.

я знаю про эти команды, речь шла о другом — о наборе команд для редактирования графа коммитов (если упрощенно считать репу графом коммитов) по аналогии с набором команд для «редактирования» фс

речь шла о наборе команд для редактирования графа коммитов (если упрощенно считать репу графом коммитов)

Внезапно, hg commit, hg merge и hg rebase. Ну и полный набор evolve.

по аналогии с набором команд для «редактирования» фс

Сова, глобус.

Сова, глобус.

и фс, и репа — ориентированный ациклический граф с метаданными в вершинах (правда репа все же чуть посложнее)

Сова, глобус.

и фс, и репа — ориентированный ациклический граф с метаданными в вершинах

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

Внезапно, hg commit, hg merge и hg rebase.

они, как я понимаю, ориентированы почти исключительно на добавление к репе — это примерно как текстовый редактор умел бы только дописывать в конец файла (а редактировать только последнюю строку), и не более того; а изредка надо именно редактировать в середине файла, причем и удалять

Ну и полный набор evolve.

посмотрю

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

я согласен сделать копию, после изготовления которой пересчитать криптохэши

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

В чем необходимость выполнять все эти операции и действия?

они, как я понимаю, ориентированы почти исключительно на добавление к репе — это примерно как текстовый редактор умел бы только дописывать в конец файла, и все, а изредка надо именно редактировать в середине, причем и удалять

Если при редактировании графа придерживаться только commit, merge и rebase, процесс редактирования сводится к созданию новых вершин (фактически подграфа) и последующему клонированию только этого подграфа через hg clone -r. Хотя rebase умеет удалять ветки со старого места, я не уверен, что для твоих задач этого хватит.

эээ... я ж вроде все объяснил?

ну например в репе есть пароль, а нужен почти клон репы, но с затертым паролем; еще неправильно сделанные коммиты — т.е. несколько коммитов в одном; или наоборот, один коммит получился размазанным по нескольким коммитам (все по недосмотру)

В чем необходимость выполнять все эти операции и действия?

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

неправильно сделанные коммиты

несколько коммитов в одном

Наверное, раз коммитер сделал несколько отдельных коммитов, так и было задумано. Т.е. с его стороны всё правильно. )

Присоединяюсь к вопросу, зачем это всё?

Например, работа сделана наспех и хочется ее облагородить (оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

фс тоже бывает иммутабельна

тогда иммутабельную фс можно скопировать на мутабельную, мутабельную «отредактировать» путем mkdir/rm/mv/cp/ln, затем залит полученную фс на уже вторую иммутабельную фс

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

Наверное, раз коммитер сделал несколько отдельных коммитов, так и было задумано. Т.е. с его стороны всё правильно. )

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

эт же скрипты, все правится наживую и почти всегда без тестов

(оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

не оставим

там были кое-какие скрипты, которые я счел deprecated и удалил (не из истории конечно, а hg remove) — теперь я хочу их вернуть обратно, но в директорию deprecated — пусть там валяются, иногда они нужны

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

фс тоже бывает иммутабельна

Может быть. Я просто таких не знаю. Ну а ФС, провязанных криптохешами, я совсем не знаю.

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

Это всё должно исправляться по ходу дела, через mq или evolve. Редактирование уже готовой репы себя не оправдывает.

(оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

не оставим

Да я чисто из вежливости сказал. Редактирование готовой репы - дурь и деццтво, за исключением случая с утечкой. Говорю как человек, в свое время страдавший этим.

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

скрипты

Хотя, если здесь hg использовался как средство доставки до места (сервера), может и есть смысл.

ы? вот SquashFS иммутабельна же?

Это всё должно исправляться по ходу дела, через mq или evolve. Редактирование уже готовой репы себя не оправдывает.

по ходу дела это просто можно не заметить, да и некогда

кроме того, для этого нужно переключаться на совсем другую деятельность — на борьбу с dvcs

Да я чисто из вежливости сказал. Редактирование готовой репы - дурь и деццтво, за исключением случая с утечкой. Говорю как человек, в свое время страдавший этим.

раз в квартал можно — тем более, это еще и обзор того, что там в репе происходит

вот SquashFS иммутабельна же?

Ну тогда любая ФС на CDROM явлется иммутабельной.

переключаться на совсем другую деятельность — на борьбу с dvcs

Нужно освоить средства, имеющиеся в DVCS. Например, вышеупомянутые mq и evolve.

Да я чисто из вежливости сказал. Редактирование готовой репы - дурь и деццтво, за исключением случая с утечкой. Говорю как человек, в свое время страдавший этим.

раз в квартал можно

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

Если перенесёшь всё в git (зачем, кстати, у тебя этот тег?), то сможешь воспользоваться git-filter-branch (это пункты 1, 2, 3, 4 автоматической обработкой скриптом) и git-rebase (ручная работа с остальными пунктами, нужен ключик -i для интерактивного режима)

а редактирование фс как? всякие там mv и ln тоже деццтво?

я к тому, что принципиально репа не сильно сложнее фс

зачем, кстати, у тебя этот тег?

потому что вопрос по сути dvcs-agnostic (и то, что реально репа в меркуриале, дело почти не меняет)

а редактирование фс как? всякие там mv и ln тоже деццтво?

Деццтво - это не понимать, что репа и ФС - разные вещи.

Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

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

а как надо организовывать работу, чтобы легко исправлять хотя бы типовой случай «коммит с фичей А, коммит с фичей В, коммит с фичей С, коммит с исправлением бага в фиче А» --amend же вроде только к последнему коммиту?

по-моему тебе ясно, что я разницу понимаю

на самом деле все вопрос опыта — на перфекционизм в виде «редактирования» ФС можно потратить неограниченное количество времени, а потом приходит понимание, когда оно нужно, а когда нет

и еще разница в том, что для фс есть набор «mkdir, rm, mv, cp, ln, awk» который де-факто стандарт, а для dvcs нет, и поэтому в dvcs времени можно угробить на порядки больше

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

--amend же вроде только к последнему коммиту, не?

Принципиальная ошибка. Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

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

но даже и в таком случае может выясниться, что в еще более будущем описание надо бы поменять

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

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

Принципиальная ошибка. Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

наконец, работу вида «объединить старый коммит с исправлением бага с новым коммитом, удаляющим упоминание о баге в другом месте» можно было бы поручить менее квалифицированному помощнику — пусть он работает на подхвате и экономит время более квалифицированного программиста

затирание паролей

удаление коммита (где фактически был затерт пароль — в будущем этот коммит не нужен)

из чужих бэкапов не удалить, поздно пить боржоми

Да, я это про случай

в результате первого коммита че-то заглючило, пришлось глюк исправлять вторым коммитом

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

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

После пуша? Однозначно неправильно. Ты же сломаешь всем всё. Ну а до пуша уж каждый волен делать что хочет.

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

по-моему тебе ясно, что я разницу понимаю

Если бы понимал - не возвращался бы к этой аналогии (которая даже формально неверна - ФС не является DAG).

В остальном - been there, done that. Никакого профита. И кстати - ты же понимаешь, что каждый отредактированный коммит нужно проверять так же, как новый? И, возможно, последующие за ним коммиты?

которая даже формально неверна - ФС не является DAG

ты про . и .. ?

это всего лишь деталь реализации DAG, которая ускоряет поиск противоположного конца ребра, и не меняет сути

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

или, допустим, не любой DAG является фс, если у нас hard link not allowed for directory

но то что ты написал это совсем странно

это всего лишь деталь реализации DAG

DAG с циклами. Окей.

В остальном - been there, done that. Никакого профита.

путеводитель по подводным граблям — это, по-моему, самое интересное чтиво; я слушаю

И кстати - ты же понимаешь, что каждый отредактированный коммит нужно проверять так же, как новый? И, возможно, последующие за ним коммиты?

что в нем надо проверять?

если в dvcs будет храниться инфа о том, что «отредактированный коммит» является например суммой двух других коммитов, то проверять его и не особо надо (в том смысле, что дифф нового коммита это конкатенация диффов двух старых)

или в более сложном случае пропали коммиты A,B,C,D,E но появились F,G,H так что A+Е+C+В+D=F+H+G, тоже проверять не особо много надо

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

вот попробуй сделай инъективное отображение произвольного графа в DAG, которое бы переводило вершины в вершины, ребра в ребра и сохраняло инцидентность — по-моему, у тебя ничего не выйдет, а вот с графом ФС вполне получается... вроде...

проблема в том, что не любой DAG представим в виде ФС, а то бы я предъявил биекцию

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

по-моему, проще всего рассмотреть ФС, где разрешены хардлинки на директории, и ссылок вида .. не одна штука, а несколько — ровно по одной штуке на каждую родительскую директорию

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

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

кстати, это, вероятно, самый простой способ.

сначала хотел предложить встроенный плагин histedit, но там нет split. поэтому таки да, только evolve

сначала хотел предложить встроенный плагин histedit, но там нет split. поэтому таки да, только evolve

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

hg cp, hg mv, hg rm

а хочется что-то типа hg batch rm, т.е.

hg update 1234 # 1234  это *старая* ревизия
hg batch rm passwords1.txt # удаляет passwords1.txt во *всех* зависимых ревизиях
hg batch replace '$password2="secret";' '$password2=get_password_2();' file1.pl file2.pl file3.pl # заменяет текст во *всех* зависимых ревизиях
hg batch commit

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

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

для расширения кругозора вполне пригодный вариант; как называются встроенные средства гита для этого? waker

После пуша? Однозначно неправильно. Ты же сломаешь всем всё. Ну а до пуша уж каждый волен делать что хочет.

это, по-моему, недоработка dvcs (и hg evolve предлагает этому одно из приемлемых решений — секретные и драфтовые ревизии)

man git-rebase, man git-filter-branch. возможно есть и другие.

evolve проще