немонотонные таймстампы коммитов в свн

в Вилларибо git давно зевезли ребейз для таких целей, а в Виллабаджо убогом svn переживают за монотонность таймстемпов. Лалки…

Не могу удержаться. В одном посте svn и:

есть репозиторий, в нём уже коммиты за 2022 год есть

В 2022 году svn?.. Мне кажется, я уже в 2012 году забыл, что это такое. Ну, не потому что svn плохой, для своего времени он был хорошим улучшением после примитивных cvs (или там Source Safe у мелкомягких), просто потому что уже тогда не оставалось ни одного резона им пользоваться. А вот резоны пользоваться Mercurial или git были уже очень весомые.

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

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

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

Ничего не сломается от такого фокуса?

А сколько timestamps в SVN ассоциированы с коммитом? Если только один - checkout as of date однозначно съедет, не знаю насколько Вам это критично.

В 2022 году svn?.. Мне кажется, я уже в 2012 году забыл, что это такое.

Они так никогда и не пофиксили фундаментальную проблему “rename” которая не является отдельной атомарной операцией а на самом деле пара “remove + add”, что полностью ломает “merge”. Одна из причин почему я даже и не начинал им пользоваться, даже для домашних “pet projects”.

А вот резоны пользоваться Mercurial или git были уже очень весомые.

Очень сильное утверждение. В частности git хорош для distributed development и когда Вы можете себе позволить atomic builds (зачекаутили коммит и пересобрали этот конкретный snapshot полностью). Но это работает далеко не везде и не всегда. Если сборка «с нуля» занимает часы это становится непростительной роскошью. А как только “base is shared” и постоянно под Вами меняется Вы будете кровно заинтересованы в информации о revision каждого конкретного файла попавшего в данную сборку, и их consistency. Одна из причин почему мы до сих пор на CVS (да да да, в 2022ом, при codebase в несколько десятков MLOC).

просто потому что уже тогда не оставалось ни одного резона им пользоваться

Есть резон когда это корпоративный стандарт.

Если сборка «с нуля» занимает часы это становится непростительной роскошью.

Сторонники Git вам расскажут что вы нищеброд. Хром – огромный проект и проблем с Git они не имеют.

Есть резон когда это корпоративный стандарт.

Можно это и так называть, но эти стандарты не на пустом месте берутся.

Сторонники Git вам расскажут что вы нищеброд.

Конкретно этим людям я могу только пожелать быть таким же «нищебродом» (правда). Но сарказм был услышан.

И ни в гите, ни в обёртках нет версионности действий над ветками

git reflog

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

Ну или в ветку другую запихни. Они ж в svn поддерживаются.

А сколько timestamps в SVN ассоциированы с коммитом? Если только один - checkout as of date однозначно съедет, не знаю насколько Вам это критично.

Ну, собственно время коммита, оно одно. Про checkout as of date даже не думал, вроде бы в автоматизированном режиме такого всё равно нет да и не нужно было бы, а вручную нужный коммит конечно и так и так можно найти.

Они так никогда и не пофиксили фундаментальную проблему “rename” которая не является отдельной атомарной операцией а на самом деле пара “remove + add”, что полностью ломает “merge”. Одна из причин почему я даже и не начинал им пользоваться, даже для домашних “pet projects”.

Ну вообще-то не remove+add а copy+remove. А как копирование реализовано на низком уровне - не так уж важно. Если мерж не умеет такие ситуации обрабатывать - это проблема логики мержа, а не логики переименования.

Одна из причин почему мы до сих пор на CVS (да да да, в 2022ом, при codebase в несколько десятков MLOC).

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

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

Ну добавь комментарий к коммитам, что взято из далёких времён.

Это всё понятно. Я ещё делал так - ls -al > filelist.txt и коммитил этот файл рядом с остальными. Но вот захотелось нативно время указать, вроде бы ничего не мешает но на всякий случай спрашиваю.

ни одного резона

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

В Haiku делают теги для каждой ревизии. Так что последовательные номера в Git можно сделать.

Зойчем им этот костыль?

С последовательными номерами удобнее работать, чем с «605761f47a6f54ef75282bd184c8972af6fcc1f5» где не поймёшь что идёт за чем и сколько изменений уже успели сделать с момента последнего обновления.

Глядя на git репозиторий дерева portage, который ведёт свое начало с 2015 года, пытаюсь представить, как была бы полезна информация сколько изменений уже сделано и что за чем идёт (изменения по сути независимы в основной массе). Там у разработчиков десятки тысяч коммитов за 7 лет.

В смысле, не поймёшь? У проекта есть релизы, релизы - это релизные ветки или теги.

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

А даже если проект не ведёт ни ветки, ни теги (тогда они сами себе буратины, конечно, но я такого не видел ещё никогда), то в чём проблема использовать номера ревизий, чтобы сравнить свою последнюю ревизию с HEAD?

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

У проекта есть релизы, релизы - это релизные ветки или теги.

В Haiku релизы редкие и довольно бесполезные. Почти все сидят на ночных сборках где ревизия используется для указания версии системы. Ночные сборки принято не ломать, а непроверенные изменения отлаживать отдельно.

то в чём проблема использовать номера ревизий, чтобы сравнить свою последнюю ревизию с HEAD?

Для этого надо Git запускать, а номерами и так всё видно, а также номера понятны любому человеку в том числе не близкому к программированию. При сообщении о проблемах проще сказать hrev123456, чем «605761f47a6f54ef75282bd184c8972af6fcc1f5».

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

Насчёт постоянной вовлечённости и набегов не очень понял.

Против свозной нумерации ничего против не имею.

По поводу меркуриала меня всегда настораживало, что там запросто может возникнуть ситуация, когда одновременно 2 ветки стменем default, нумерация при этом сквозная. Особых усилий для этого не нужно. А при некоторых манипуляциях обе будут локальными (всё коммиты draft)

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

git log --author-date-order?

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

author date ещё хуже, это по идее дата написания кода, от неё до коммита может пройти произвольное время

Я так понимаю, если ничего специально не ломать это будет дата создания оригинального коммита, в последствии не меняющаяся при amend / rebase итд.

но если где-то нужен именно централизованный учёт коммитов

Я прекрасно понимаю Ваши проблемы.

Это после гита непривычно. А так, просто две безымянные «головы» в одной ветке, чего непонятного :)

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

Прочитав заголовки, подумал про какие-то коммиты в стиле Monotone https://www.monotone.ca/

А почему эти немонотонные-то?

А я вижу резоны не пользоваться гитом.

Правильно, надо пользоваться monotone. Там все коммиты монотонные.

Это после гита непривычно

Я сначала с tortoisehg познакомился (консольный hg не трогал),а потом уже с git. Для личных целей мне ртутной черепахи хватает.

сколько и какие коммиты с момента твоего последнего обращения к репозиторию появилось

В моем случае, лучше не знать сколько :( а в случае «какие изменения» я смотрю изменения в конкретном каталоге. Главное в проекте, чтобы описание коммитов было вменяемым, а не в стиле «внесли изменения в этот файл».

А почему эти немонотонные-то?

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

Я сначала с tortoisehg познакомился (консольный hg не трогал),а потом уже с git. Для личных целей мне ртутной черепахи хватает.

Ну тогда тем более, в чём проблема с безымянными головами?.. в гите сделано так, что все головы должны иметь имя, что не всегда удобно ИМХО. В принципе, привыкнуть можно, но иногда просто лишняя возня возникает...

С последовательными номерами удобнее работать, чем с «605761f47a6f54ef75282bd184c8972af6fcc1f5»

Лорчую.

в чём проблема с безымянными головами?

Сложно понять сходу какая основная, особенно, если в них пилится одна фича с разной реализацией.

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

В гите это не просто нельзя сходу узнать,

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

А в гите кстати вообще по метаданным коммита невозможно определить когда он был включён в репозиторий (запушен)

Тебе нужно именно дату, когда коммит был запушен в удалённый репозиторий? Или нужна дата фиксации коммита локально? Поле CommitDate не подходит? Конечно, его тоже можно подделать, но это явно не частое явление.

При сообщении о проблемах проще сказать hrev123456, чем «605761f47a6f54ef75282bd184c8972af6fcc1f5».

Лучше просто при сборке прошивать в бинарники информацию о состоянии, из которого был собран проект. И тогда будет без разницы, какую строку копировать, «hrev12309» или «d098d0bdd181d182d180d183d0bcd0b5d0bdd182».

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

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

Тебе нужно именно дату, когда коммит был запушен в удалённый репозиторий?

Формулировка не полностью отражает смысл, но да.

Или нужна дата фиксации коммита локально? Поле CommitDate не подходит? Конечно, его тоже можно подделать, но это явно не частое явление.

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

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

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

Похоже, ты не понимаешь и не хочешь понимать отличия Git от Subversion.

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

Только не надо по второму кругу идти, я сейчас даже полное его содержание напишу:

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

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

Моя самая большая ошибка, по крайней мере в этом треде, состоит в том, что я воспринял твоё нытьё как вопросы и попытался на них ответить.

Гит не умеет нормально реализовывать централизованный репозиторий

Может быть Gerrit это то что Вы ищете?

Моя самая большая ошибка

Я пожалею что влез, сто-пудово. Мне кажется Вы не до конца понимаете business processes @firkas имеет дело with.

ПыСы. А почему он выпилился?

О! Некрофилии тред! И фанаты hg тоже отметились. Осталось только чтобы кто-то с darcs вылез. Есть кто с darcs?

А вот у свн с этим проблем (при штатном использовании), почему-то, нет.

Потому что коммит сразу оправляется на сервер? Существует ситуация, когда он создан и лежит неделю перед отправкой?

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

Тэги?

Ну вот в Haiku и сделали теги для каждого номера ревизии чтобы было как в SVN.