GitHub, M$ и SourceForge

[vitus_wagner]

На /. пишут, что MicroSoft покупает GitHub. Официально сделка еще не объявлена, но инсайдерские источники утверждают что стороны пришли к соглашению.

По этому поводу SourceForge выкатила GitHub importing tool, надеясь что народ с гитхаба теперь ломанется, а куда крестьянину кроме сурсфорджа-то податься?

Вообще похоже надо фрешмит возрождать. В смысле делать поисковик по проектам которые хостятся хрен знает где. Но с учетом нынешней моды на распределенные VCS делать его таким, чтобы он показывал, где СЕГОДНЯ находится главный репозиторий проекта.

Для этого стырить микрософтовскую же (уже забытую самим M$) технологию выбора мастер-бровсера в SMB и прикрутить ее к распределенным VCS.

Upd еще пост на слэшдот

Upd2 О сделке уже объявлено.

Comments

[avnik]

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

Аналог freshmeat это хорошо, особенно если он будет таким "гуглом" (в смысле, что будет иметь свой поисковый бот, и будет искать проекты сам, а не ждать пока кто-то (автор) почешется его туда добавить). Предполагаю, что похожий функционал появится где нибудь в районе repology в ближайший год (если наступит таки разбегание).

[vitus_wagner]

Скайп после его покупки M$ стал портиться исключительно быстро.

[avnik]

сложно было испортить то, что всегда было говном.

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

Тем не менее, МС это удалось

[bakaneko]

("испортить то, что всегда было говном."
Как в классическом пирожке:
"... а если за говно берётся
то просто тратит меньше сил")

"В моей вселенной" всё хуже: на одни компьютеры не ставится, на других не запускается, на третьих не работает (как в м/ф "Дудочка и кувшинчик".
С некоторыми абонентами соединяется через раз -- как в "Не можем отправить почту далее 500 миль".)

(На хабре говорят, что в _совсем_ последнее время он стал улучшаться, но дна достигал однозначно.)

[phd_ru]

Ага, с конфигами прикольно было.

У меня клиент вообще перестал работать — у меня 32-битный Linux, а Скуп теперь исключительно 64. Тоже пользуюсь web-версией.

[avnik]

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

[phd_ru]

Мы точно про десктопный Skype говорим? В десктопном Скупе было множество настроек, которых нет в web-версии. Например, скрипты, которые вызываются по событиям, причём событий было десятка 4. У меня было 2 скрипта — когда я отвечал на звонок, он писал в Gajim/Pidgin статус «Говорю по телефону», а когда я завершал разговор, соответственно, наоборот "Online/Available".

[avnik]

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

[avnik]

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

[phd_ru]

Мнэ? У Gajim и Pidgin с конифгами никаких проблем. Пользуюсь много лет.

[tzirechnoy [lj.rossia.org]]

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

[nasse]

А почему ты думаешь, что она забыта, эта технология?

[vitus_wagner]

Да тут мне пытались доказать что SMB вообще deprecated. А еще потому что у меня десятка регулярно отказывается ходить на самбу по имени, только по IP.

[jahr]

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

Я возможно ошибаюсь, но, по-моему, стандартная практика использования гита с этим вполне согласуется (у меня в любом локальном репозитории штук по пять remote, а cherry-pick - одна из частых комманд).

[vitus_wagner]

Репозиторий это не только и не столько множество (дерево) коммитов.
Это еще и issue tracker, который как бы не важнее коммитов, это wiki, бинарные тарболлы релизов (которые в первую очередь нужны пользователям).

Засада в том, что git сам по себе ничего этого не умеет. Он полагался на внешние сущности вроде gilhub-а и gitlab-а. Хотя есть проекты, в которых все это внутри, но они менее популярны.

В общем для настоящей распредленности надо сначала из git сделать fossil, а потом уже решать проблему поиска нужного источника для clone в сети.

[jahr]

Мне все-таки кажется, что это должны быть отдельные продукты (с хорошей интеграцией). Зачем все сваливать в один комбайн, теряя в гибкости и преврашаяясь в тяжеловесного монстра? Чем именно встроенный issue-tracker лучше реализованного отдельно при наличии возможности подключения всякой автоматической интеграции? А почему бинарники не раздают торрентом, а хостят на сайте - мне вообще не ясно.)

[vitus_wagner]

меньше 2 мегов, это тяжеловесный монстр?

vitus@fafnir$ ls -l /usr/bin/fossil
-rwxr-xr-x 1 root root 1992504 янв 18  2017 /usr/bin/fossil

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

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

[avnik]

у "аналога" fossil поверх гита шансов выстрелить существенно больше чем у самого фоссила.

[vitus_wagner]

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

[avnik]

ну я не буду спорить за Хипп vs Торвальдс, я мало что могу тут сказать.
Но гит сделан прагматичнее по моему. И там хорошо прослеживаются абстракции (первые версии гита же вообще были кучей шелл скриптов насколько я помню). Хотя я в кишки фоссила не смотрел, как он устроен не знаю -- если у вас есть возможность кратко сформулировать (на абзац) -- сделайте плиз.

[vitus_wagner]

А по-моему, нет. В том-то и дело, что git всегда был свалкой скриптов и модулей, не имеющей связной системы абстракций.

Поэтому, скажем, для того чтобы поставить git в windows, требуется принести туда половину msys.

fossil это один бинарник, котрый просто копируешь и им же регистрируешь как сервис. и voila, твой виндовый тостер превращается в полноценный сервер SCM, с которого можно делать pull и clone.

А если тебе надо не посторонних людей пускать а самому воспользоваться web-интерфейсом локально (по вики там полазить с поиском, issues поменеджить) то и сервиса регистрировать не надо.

Проблем с firewall penetration тоже нет. Все ходит поверх либо http(s), либо ssh.

А форматом хранения является база sqlite, благо автор у них общий.

И еще - в git предусмотрена орвеллианская возможность редактирования прошлого - переупорядочения прошлых коммитов, --amend и прочие rebase. Которые как правило приводят к очень большим граблям, если старые коммиты уже успели уехать в удаленные репозитории. В fossil история вечна и неизменна, что сильно снижает проблемы синхронизации по схеме, отличной от звезды.

Конечно, у fossil есть и недостатки. Например, отсутствие глобального пространства имен пользователей. И в нашем случае, при замене github на распределенную сеть, этот недостаток становится существенным. Впрочем в git, где коммитеры идентифицируются E-mail-ами и эти E-mail-ы никак не верифицируются, все тоже не слишком хорошо.

[avnik]

> А по-моему, нет. В том-то и дело, что git всегда был свалкой скриптов и модулей, не
> имеющей связной системы абстракций.

Ну почему же, там есть уровень работы с raw объектами (cat-file/hash-object/git-mktree). Есть уровень хранилища (raw files и indexed packs, можно хоть тот же sqlite добавить -- по идее любой k/v storage подойдет).

> Поэтому, скажем, для того чтобы поставить git в windows, требуется принести туда
> половину msys.

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

> И еще - в git предусмотрена орвеллианская возможность редактирования прошлого - переупорядочения прошлых коммитов

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

Идеологически же рассуждать нужен ли ребейс можно долго, учитывая что его и для синхронизации сильно разъехавшихся веток используют, и еще много для чего. И в том что перед публикацией бывает надо подчистить код тоже правда (если я в приступе мигрени off-by-one посадил в тривиальном алгоритме, а нашел только на утро, мне это что -- всему миру показывать?)

Формат артефактов у фоссила сделан чуть поумнее чем tree/commit объектов у гита, видимо просто в силу того, что позже и какие-то детские болезни гита были уже видны.

Формат tree (aka manifest у фоссила) -- тут я вижу плюсы и минусы у обоих. У фоссила можно использовать разные алгоритмы хешей (втч добавлять новые), у гита sha1 забит гвоздями. Я бы честно говоря взял какой нибудь multihash формат записи, который в себе несет тип хеша. Минус у фоссила, что у него 1 манифест на весь коммит, а не tree на каждый узел файлового дерева. Для больших проектов типа ядра, оно будет делать многомегабайтные манифесты на каждый мелкий коммит.

Ну и гит в силу своей текущей реализации (libgit, много мелких утилит) -- предполагает, что его можно использовать как хранилище другими софтами. Багтрекер (как минимум один) на базе гита я видел -- bug everywhere, вот как можно что-то сделать на базе фоссила без поддержки его автора -- я плохо представляю.

[vitus_wagner]

Вообще-то никто не мешает фоссил форкнуть, как и любой проект c BSD-лицензией. То есть берешь и делаешь. Но как раз багртракер там уже есть.

Кстати, кроме bugs-everywhere есть еще ticgit, который на мой взгляд, имеет большое преимущество - он хранит баги не в директории, а в ветке. Поэтому если проект использует какую-нибудь CI-систему, операции с баг-репортами не будут триггерить билдов.

[iws]

В целом, Git неплохо расширяется, и Issue и Pull Request'ы можно в виде таких расширений сделать, а если они будут широко использоваться и хорошо поддерживаться, то и в апстрим продвинуть можно (как расширения же, но «стандартные»).

Бинарные тарболы, да и вообще системы сборки, мне кажется, что-то отдельное должно быть. Хотя бы потому, что пилить единую систему сборки для всего на свете, как-то сомнительно.

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

[vitus_wagner]

git СЛИШКОМ хорошо расширяется. Поэтому его расширяют разными и несовместими способами.

По части issie tracker-а, я бы конечно, проголосовал за ticgit.

Но есть, например git-issues, bugs-everywhere и т.д.


И наверняка еще десяток можно найти.

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

О запуске web-интерфейса прямо над рабочей копией, как это сделано в fossil, тоже.

[iws]

>> git СЛИШКОМ хорошо расширяется. Поэтому его расширяют разными и несовместими способами.

Ну, я вот это тоже хотел сказать.


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

[livelight]

А зачем одному локальному репозиторию пять ремоутов? Один - типа аплинк, а остальные 4 для чего?

[allter]

Ну, например, у меня бывает для "рабочих" чекаутов: 1 аплинк в gitlab, 1 bare-локальная копия, 1 "чистый" чекаут, через который идёт пуш, 1 dev-чекаут на выделенном сервере. Часто при копировании рабочих виртуалок (по cp -R ) добавляются ещё "соседние" рабочие чекауты. Плюс дополнительные устройства иногда...

[lumag]

Аплинк, даунлинк, пиры для обмена патчами. Пять — это мало. 10–12 — это норма.

[jahr]

origin (мой репозитарий на гитхабе, из которого я создаю pull request'ы в репозитарий проекта), upstream (официальный репозиторий проекта), апстрим апстрима (проект, от которого был форкнут upstream, нужен для backport'а функциональности, которая будет полезна и которая добавлена после форка), несколько репозиториев других разработчиков проекта - аналогов моего origin (нужны для предварительных тестов их новой функциональности и согласования того, что мы пишем). Иногда добавляются еще какие-то другие форки базового проекта из которых тоже может захотеться портировать что-то полезное.) Репозитории других разработчиков можно было бы убрать, если бы у всех были права записи в основной репозиторий и "черновая" работа велась бы в каких-то ветках основного проекта каждым, но, мне кажется, тогда в основном репозитарии совсем путаница была бы.)

[afa_at_work]

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

[vitus_wagner]

А кто будет issue tracker-ы синхронизировать?

[afa_at_work]

а вот issue оттуда - нафиг. даже pivotal лучше. вот кодревью - да, неудобно в куче мест синхронить.

[vitus_wagner]

Откуда оттуда? Из гитхаба?

Да наплевать на то что лучше, а что хуже. Важно где тусуется народ, способный постить вменяемые багрепорты.

[afa_at_work]

из любой обёртки вокруг гита.
ай, ладно. время было, монолитных комбайнов.

[vitus_wagner]

Гитхаб это не обертка вокруг гита, а социальная сеть такая. В этом-то и проблема. Чтобы из распределенной VCS сделать распределенную социальную сеть, надо еще много работать.

[nataraj]

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

[vitus_wagner]

Суть социальной сети не в лайках, а в поиске друзей. В данном случае контрибьюторов и баг-репортеров.

[afa_at_work]

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

[vitus_wagner]

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

Но вообще поделка на рельсах за 7.5 гигабаксов это круто. Учитывая, что целая Монсанта пошла всего-то за 63.

[afa_at_work]

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

а так да. прикольно. мы пилили-пилили и напилили.

SourceForge -- это же те "красавчики",

[bakaneko]

которые добавляли всякую ерунду в инсталляторы, которые с них скачивались?

Re: SourceForge -- это же те "красавчики",

[vitus_wagner]

Нет, там с тех пор собственник поменялся.

Голосом Оби-Вана

[pargentum]

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