Были ли попытки создания системы децентрализованного хранения opensource-кода? По типу торрентов. Чтобы репозитории синкались (дублировались) по выбору владельцев нод?
Вообще-то git такой и есть. Никто тебя не заставляет синкаться с центнральным hub'ом. Можешь себе спокойно, федереративно синкаться со всеми своими контрибюрерами. Только вот сложность синхронизации при таком раскладе растёт, как O(n!), вместо O(n), как при цернтральном hub'е.
В zeronet нечто подобное есть. Git Center называется.
Git Center is a decentralized hosting platform for Git repositories. We provide several collaboration features such as bug tracking for every project, and private and public repositories for free. Join us by creating a new repository.
Такой, да не такой. Git'у нужно где-то держать сервер. И «Git» это уже давно не только репа, но, как минимум, ещё и обмен Issues, пулл-реквесты и т.п. :)
Фантазирую на ходу: Каждый хост имеет свой приватный ключ. Проект, при создании, подписывается ключом создателя. Этот ключ становится авторизованным для этого проекта, также как и любой ключ подписанный ранее авторизованными ключами. Частью проекта считаются только изменения подписанные авторизованными ключами. Публичный ключ создателя проекта является частью указателя на проект (того что нужно написать после условного git clone чтобы получить сырцы). Склонировав проект и внеся в него изменение подписанное не авторизованным ключом мы создаём новый, дочерний, проект. Ну и должен быть какой-то механизм с помощью которого владелей авторизованного ключа может включить в проект изменения из другого (дочернего) проекта.
Поставщиком единой правды в таком варианте является приватный ключ владельца проекта.
Дальше одного хоста сервер нужен, но он не обязательно должен быть централизован (можно поднять каждому клиенту свой сервер и спокойно работать; я делал так с локальной сетью в четыре компа, где все четыре были и клиентами и серверами; оверхед, но это чуть большая свобода).
Но это давно уже необходимый инструмент разработки.
Никто не мешает поднять что-нибудь отдельное. Для Git даже веб-морда не нужна.
И как я их смогу у тебя скачать без сервера?
Я говорю о локальной работе на один локалхост. Если нужна небольшая локальная сеть, то можно поднять сервер, причём даже на каждом клиенте. (%
можно поднять каждому клиенту свой сервер и спокойно работать
Угу. Только придётся как-то решать вопрос взаимодействия этих серверов при коллективной разработке. И в конце решения этой задачи единообразно и автоматизированно, мы и получим то, что ищется в теме. Или что-то типа GitCenter.
Я говорю о локальной работе на один локалхост
Это совсем другие задачи, чем те, что породили данный топик.
А зачем, все настолько нищие что не могут купить VDS за 100 рублей ради gitea? Или платных возможностей где-нибудь на bitbucket? Для совсем-совсем нищих или ленивых полно бесплатных хостингов, в случае чего можно мигрировать.
Чисто теоретически идея интересная. Но на неё нет большого спроса, чтобы родилась хорошая и удобная реализация. А для фанатиков, как уже было сказано, есть ZeroNet с его zero-плюшками.
В рамках проекта GitPub началась подготовка спецификации, расширяющей протокол ActivityPub средствами для объединения Git-сервисов в общую федеративную сеть. Изначально ActivityPub рассчитан на распространение контента, управление подписками и доставку уведомлений в децентрализованных социальных сетях (позволяет объединять контент социальных сетей на основе отличающихся платформ), но протокол создан с возможностью расширения и может быть легко адаптирован для организации взаимодействия между сервисами совместной разработки.
Первый черновой вариант спецификации GitPub определяет API для трансляции между серверами pull-запросов и операций создания форков, а также оформления подписки на репозитории, предоставляемые web-сервисами наподобие GitHub, GitLab, RhodeCode, GitPrep, Kallithea, GitBucket, Gogs и Gitea. Спецификация поставляется под лицензией W3C Document License, а примеры кода под лицензией MIT.
GitPub охватывает только аспекты взаимодействия между серверами (server-to-server), не углубляясь в низкоуровневые git-операции и не привязываясь к конкретным реализациям серверов. В отличие от API Apache GitPubSub, GitPub фокусирует внимание на обеспечение выполнения операций, охватывающих разные репозитории (форки, pull-запросы), в то время как GitPubSub рассчитан на передачу сведений на уровне отдельных коммитов в конкретном репозитории.
Давайте определимся. Какую проблему вы хотите решить, из тех, что не решается git'ом?
Git децентрализован. В том смысле, что нет «центрального» узла, выход из строя которого затруднит или сделает невозможной работу остальных.
Git позволяет делать синхронизацию.
От них ко мне командой fetch (pull - это fetch+merge).
От меня к ним командой push, или выполнением fetch/pull с их стороны, откуда и название pull request.
Есть механизм хранения списка нод - remotes.
Хочется автоматической синхронизации - поставьте на cron команду fetch со всех нод.
Но git'у (в отличии от, например, svn) сервер нужен только для синхронизации нод, при этом сервером является одна их них. Все остальные действия, касающиеся непосредственно работы, прекоасно обходятся без него. И любая нода в любой момент может стать сервером.
Есть разница между сервером TCP/IP взаимодействия и выделенным сервером.
Т.е. формально даже для обмена файлами по smb нужен сервер, но им может быть любой участник взаимодействия или даже все одновременно. Выделенный сервер для этого не нужен.
И у torrent, внезапно, каждый качающий тоже сервер.
Кэп? Для любого сетевого взаимодействия нужен сервер.
Мы уже ушли очень далеко от исходного предмета спора. Было утверждение, что Git'у не нужна децентрализованная система, поскольку он итак уже децентрализованный. На что и было возражение, что сам по себе Git, пусть и будучи децентрализованной системой хранения, не является децентрализованной системой обмена репозиториями. И для реализации нормального p2p ему нужна ещё какая-то обвязка. Из-за чего был открыт топик. И возражения «Git'у это не нужно, поскольку он итак это умеет» абсолютно некорректны :)
И вы и тс ссылаетесь на какой-то предыдущий разговор, породивший данный. Было бы неплохо, если бы вы дали ссылку, тем самым позволив остальным понят, что вы подразумеваете, но не озвучиваете.
возражения «Git'у это не нужно, поскольку он итак это умеет» абсолютно некорректны