Fossil SCM 2.28

Кто-то из местных истользует fossil? Какие истории узбека есть?

А чего, с гитом так нельзя сделать, чтоб вот это вот всё

одновременно является VCS, встроенным веб-сервером, багтрекером, вики, форумом и чатом

было в одном контейнере вместе с репой, который можно развернуть одной командой на VPS за $5?

Кто-то из местных истользует fossil? Какие истории узбека есть?

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

fossil server

hg serve ^_^

разрабатываемой автором SQLite

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

я
пока

Вот именно...

Весьма неплохо. Для себя или ограниченного коллектива авторов поприятнее чем git. Не очень подойдёт если разработка в варианте «100500 мимокрокодилов с push request’ами».

А ещё в отличии от git в fossil нету позорного CoC. :)

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

уж зарелизили так зарелизили ;-)

SQLITE_MISUSE(21): misuse at line 189778 of [557aeb4386]

то есть день-два придётся обождать, до bug-fix

PS/ или брать 2.29, что вполне работоспособно. Сайт и репа fossil на 2.29

Сам пользовался? Скажи, а во встроенном веб-интерфейсе есть механизм авторизации, логины, пароли, всё такое?

(Кажется, я этот вопрос на ЛОРе уже задавал, но поиском найти сейчас не могу. Поэтому всем причастным и отвечавшим приношу извинения.)

а во встроенном веб-интерфейсе есть механизм авторизации, логины, пароли, всё такое?

Есть.

Кажется, я этот вопрос на ЛОРе уже задавал, но поиском найти сейчас не могу.

Тут: Fossil SCM 2.27 (комментарий)?

О, спасибо!

Fossil :)

высоконадёжной распределённой

весь проект — это один исполняемый файл

который одновременно является VCS, встроенным веб-сервером, багтрекером, вики, форумом и чатом

LOL! Интересно что имеется в виду под «распределённостью»? Как и куда он собрался единственный бинарь распределять?

Интересно что имеется в виду под «распределённостью»?

https://ru.wikipedia.org/wiki/Fossil:

Интересной особенностью Fossil является то, что, хотя он представляет собой распределённую систему хранения версий подобно GIT или Mercurial, но вместе с тем позволяет работать пользователю с централизованным хранилищем как CVS или SVN. Эта возможность реализована за счёт режима автосинхронизации (autosync mode): после удачно завершённой фиксации изменений в локальном хранилище (commit) правки автоматически отправляются (push) обратно на сервер, с которого было клонировано хранилище или последний раз синхронизировалось. Точно так же при обновлении (update) локальных файлов Fossil сперва забирает (pull) последние изменения с сервера в локальное хранилище, а затем уже обновляет файлы пользователя. Автосинхронизация включена по умолчанию: по мнению авторов, совместная разработка в этом режиме проходит более гладко за счёт ухода от бессмысленных разветвлений/слияний и удержания разработчиков в одной и той же версии кода вместо собственных несовместимых веток.

Fossil автоматически проверяет все репозитории на целостность и непротиворечивость. Надёжность репозитория основана на использовании в качестве хранилища информации СУБД SQLite3, которая способна обеспечить атомарность исполняемых операций.

Как и куда он собрался единственный бинарь распределять?

🤡

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

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

php разизобрести обратно, остальные оставить, добавить в список aptitude - и вот он, идеальный мир

c

Это, конешно, все хорошо, но Сишка означает, что разработка будет идти медленно, фич будет мало и все такое.

Forgejo перспективней.

Приехал к проводному интернету - засинкался обратно.

Засинкался с чем?

Используем для внутрилабораторных проектов, включая fossil server, постоянно запущенный как SCGI за nginx(+TLS). Брат жив, волосы мягкие и шелковистые. Виндузятники в команде довольны, что не нужно ставить Git for Windows, но недовольны, что нет встроенной интеграции с VSCode. Мне нравится, что cherry-pick работает как полноценная операция слияния, а не как git rebase для одного коммита. Также неплохая возможность сделать fossil all sync, чтобы синхронизировать все открытые репозитории разом, после чего уйти на выходные из интернета. Веб-интерфейс отличный. Вики работает отлично. fossil pikchr - отличный наследник PIC от Брайана Кернигана. fossil uv удобно использовать для всяких там блобов, которые в историю проекта пихать не хочется, а держать рядом с ним нужно. Форум неплох. Тикеты чем-то напоминают Bugzilla, одновременно сложноваты и топорны, но пользоваться ими можно. Возможно, для болтовни на тему проекта придётся перейти на встроенный чат, хе-хе.

К системе «редактирования» коммитов нужно привыкнуть: с одной стороны, каждый артефакт в репозитории - это навсегда; rebase здесь намеренно отсутствует (хотя есть флаг private для веток, чтобы не синхронизировать их на сервер). Избавиться от него можно только при помощи сложной хирургической операции под названием shunning. (А если артефакт успели синхронизировать, то операцию придётся делать со всеми клонами репозитория.) С другой стороны, любую опечатку в коммите можно исправить путём создания ещё одного артефакта (fossil amend), который станет для него исправлением, причём в истории изменений это мозолить глаза не будет (если специально не включить показ таких артефактов). Кроме того, совсем уж ошибочный коммит можно таким образом переправить в мусорную ветку и спрятать, и вся эта процедура практически безболезненная.

Надо понимать, что это сделано для SQLite: cathedral-style development, а не bazaar-style development. Давать левым людям просто так создавать новых пользователей в репозитории я бы не стал, хотя разграничить доступ на форум и в тикеты в принципе можно.

за счёт ухода от бессмысленных разветвлений/слияний

Ага, и merge-конфликты сами собой разрешатся :)

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

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

Миллионы мух не могут ошибаться? Самое смешное то, что интеграция Fossil куда угодно вообще не составляет труда. Это Git знаменит тем, что у него запредельно всратый родной интерфейс и до некоторого времени API отсутствовал в принципе — что порождало целый класс проблем, не существующих в других VCS. Например, как сделать просмотр репозитория через браузер. Для хостинга Git разработаны огромные проекты — GitHub и GitLab. Для хостинга Fossil нужна просто любая VPS.

каждый артефакт в репозитории - это навсегда cathedral-style development, а не bazaar-style development.

Т.е. ежели в соборе чего-нибудь лишнее в репозиторий отправил, то всё, приехали? Молись и кайся?! Как-то очень жостко.

Сишка означает, что разработка будет идти медленно

это не проект «накоммитил и убежал», это проект, который развивается стабильно, постоянно и профессионально

LOL! Интересно что имеется в виду под «распределённостью»? Как и куда он собрался единственный бинарь распределять?

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

Я, конечно, не настоящий слесарь, но думаю, что имелась в виду распределённость не бинаря, а репозиториев, которые им управляются (так же, как в случае git, hg, etc).

Т.е. ежели в соборе чего-нибудь лишнее в репозиторий отправил, то всё, приехали? Молись и кайся?! Как-то очень жостко.

Как ни странно, в Git тоже нельзя удилить ветку у других пользователей. Даже если ты переписал историю и пушнул в какой-то центральный сервер — каждый владелец копии должен сделать git reset --hard origin/<branch-name>, иначе он будет продолжать работать со старой веткой, без твоих изменений. При условии, что у вас вообще есть центральное хранилище — потому что иначе нужно будет лично к каждому разрабу на поклон приходить: «прими мои изменения».

Другое дело, что в куче компаний Git используется в режиме SVN (git pull --rebase origin main), но они продолжают считать, что пользуются DVCS.

Т.е. ежели в соборе чего-нибудь лишнее в репозиторий отправил, то всё, приехали?

Не всё.

В простом случае можно «отредактировать» информацию о коммите.

В более сложном случае можно весь коммит отправить в скрытую ветку mistake и попробовать ещё раз.

В тяжёлом случае (когда просто оставить лишнее валяться в истории точно нельзя) артефакты можно внести в список нежелательных и перестроить базу. Если это сделано на сервере, клиентам достаточно сделать fossil conf pull shun && fossil rebuild.

Например в git репах MS Azure Devops удалить коммит можно только пересоздав репо. У них «вечный» reflog (см. тут)

Что касается Fossil, то в комменте выше писали про shunning. Т.е. механизм есть, но именно для исключительных ситуаций.

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

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

Ну вообще, те же git и hg традиционно называют именно распределёнными системами (DVCS, первая и последняя буква в аббревиатуре). Это не хорошо и не плохо, просто так сложилось.

может оказаться хорошим решением для развёртывания на бюджетной VPS-ке

Примерно как любой контейнер с любой VCS - там для развёртывания нужна целая одна команда.

Другое дело что рядом с хранилищем исходников нужны не чат, форум и музыкальный плеер, а система CI\CD с хранилищем артефактов. Но это всё для полноценных групп разработки, которым не важно за сколько там команд разворачиваются базовые сервисы потому что всё-равно их выполняет ansible playbook или helm chart.

То есть по факту это git

Нет, см. https://www.sqlite.org/whynotgit.html
В частности 2.4. Git does not track historical branch names
По наличию перманетных веток оно напоминает Mercurial.

необходимости разрешения каждым разрабом конфликтов на каждый коммит

Нет, это просто workflow по умолчанию при работе над одной ветке.

К системе «редактирования» коммитов нужно привыкнуть: с одной стороны, каждый артефакт в репозитории - это навсегда;

А чего к этому привыкать? По-моему git единственная VCS, где штатным workflow предусмотрено редактирование истории (в т.ч. публичной). Разве нет?

Однако заметил, что нету sparse checkout. Как вы без него обходитесь? Или у вам все на мелкие репо порезано..

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

Но в любом случае «прикрыть срам немедленно и быстро» — базовая функциональность для системы хранения версий.

Для хостинга Git разработаны огромные проекты — GitHub и GitLab. Для хостинга Fossil нужна просто любая VPS.

Что за ерунда? Для хостинга git нужен git и ssh. Никаких огромных проектов не нужно. Если хочется веб-интерфейса, там тоже выбор огромный и никаких проблем поднять веб-интерфейс на любой VPS нет.

GitHub это немного другое.

hg serve

Скромничаем и забываем указать размер пистон-дистрибутива в зависимостях к этой команде? :)

Ну вообще, те же git и hg традиционно называют именно распределёнными системами (DVCS, первая и последняя буква в аббревиатуре). Это не хорошо и не плохо, просто так сложилось.

Bittorent - распределённая система. Tor - распределённая система. Что не так? Абонент просто тригернулся на слова.

Примерно как любой контейнер с любой VCS - там для развёртывания нужна целая одна команда.

Ну и какая же команда разворачивает колаборативную платформу для git? Для SVN?

у mercurial вроде вообще зависимостей нет, а python поднять вообще не проблема, у меня на минидистре python3 был 3 мб, сколько hg уже не помню

вопрос в другом, это даже 5% fossil не покрывает

у hg serve прикольно другое

https://sprinternet.io/iii-web.php?msgid=25nfOtYz52d0ek0yIVWU

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

По наличию перманетных веток оно напоминает Mercurial.

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

То, что называется «branch» в Git, называется «bookmark» в Mercurial.

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

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

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

Но в любом случае «прикрыть срам немедленно и быстро» — базовая функциональность для системы хранения версий.

Я ещё раз повторяю: людям не нужны DVCS. То, что ты описываешь — это не DVCS, потому что в DVCS «публикуется» чья-то заранее подготовленная-одобренная копия, в которой, естественно, никаких node_modules и прочих артефактов не будет. «Мы все срём в центральную репу» — это SVN с чуть более удобным инструментом для формирования коммита.

Что за ерунда? Для хостинга git нужен git и ssh.

И как выложить репу для read-only клонирования аноном?

GitHub это немного другое.

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

По-моему git единственная VCS, где штатным workflow предусмотрено редактирование истории (в т.ч. публичной). Разве нет?

Верно, но раз уж Git есть lingua franca современной разработки, и во многих проектах перед каждой рецензией принято делать rebase и force push, приходится уточнять.

Однако заметил, что нету sparse checkout. Как вы без него обходитесь? Или у вам все на мелкие репо порезано..

Да, проекты в целом мелкие, и если нужны, то все целиком. Делать монорепозиторий поверх Fossil было бы больно. Помню, как на их форуме ломали копья про shallow clone (по датам) и narrow clone (по веткам), а вот про обсуждение sparse checkout речь зайти практически не успела.

ключи в любом случае подлежат замене

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

«Мы все срём в центральную репу» — это SVN с чуть более удобным инструментом для формирования коммита.

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

Верно, но раз уж Git есть lingua franca современной разработки, и во многих проектах перед каждой рецензией принято делать rebase и force push, приходится уточнять.

Элементарно, Ватсон, этот workflow называется patch queue, только сделанный через жопу.

По канону patch queue ты делаешь ревью патча, накладываешь его на самую свежую версию ветки, и дальше то же делаешь с другими патчами.

В Mercurial есть вполне себе явное расширение mq, которое позволяет накладывать патчи в произвольном порядке с разруливанием конфликтов через 3-way merge. Git позволяет делать то же самое, но заметно более сложными телодвижениями.

Помню, как на их форуме ломали копья про shallow clone (по датам) и narrow clone (по веткам), а вот про обсуждение sparse checkout речь зайти практически не успела.

Ну типа подразумевается, что если у вас большой проект, то вы не пользуетесь Fossil. Ни Git, ни Mercurial аналогично не решают эти проблемы, по тем же причинам.

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

Напоминаю, что SVN хранит локально полную копию последней версии ветки. В более продвинутых клиентах есть sparse clone a.k.a. offline cache:
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-showlog.html#tsv...

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

Никогда не работал с SVN, так что и сказать ничего не могу.

Никогда не работал с SVN, так что и сказать ничего не могу.

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

То есть оно ещё и с git несовместимо? Просто эталонное ненужно - эра экспериментов и конкуренции VCS уже лет 10 как закончилась. Несмотря на все его недостатки и кривизну git оказался приемлемого для большинства случаев качества.