Как стать автором
Обновить

Комментарии 51

И страницы, которые хостятся на github pages недоступны =\

Да, то открываются, то нет (по крайней мере в моем случае). На githubstatus.com "partial outage".

лёгкий, надёжный сервис GitHub - говорили они..

Майкрософт уже навели свои порядки?

А какие у неё порядки, такие же как у гугла и фейсбука? Их сервисы тоже недавно падали.

НЛО прилетело и опубликовало эту надпись здесь

К сожалению, GitHub отучает своих пользователей от того, что git является DVCS. Печально видеть, когда у команд разработчиков чуть ли не останавливается работа, если случается очередной инцидент в GitHub.

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

С CI и баг-трекером уже посложнее. Развернуть полноценную локальную копию GitHub позволяет только за большие деньги. Так что, сопоставляя риски и объем работ, предпочитаю другие решения, между которыми уже отлажена миграция в случае аварий или даже блокировок.

GitLab CE/CI пользуетесь?

С удовольствием пользуемся, отличный self-hosted git, да еще и с приятным CI.

gitlab тяжеловат на скейле. Понятно, что если 50 разрабов и 1000 репо - омнибас докер и поехали. Но если компания сколь-нибудь большая - гитлаб в периметре требует либо отдельную команду для поддержки, либо платите за лицензии...

Да. На некоторых проектах в качестве CI — Jenkins.

Я использую Fossil и мне кажется, что это то что вам нужно.

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

А вы возьмите и осмельтесь однажды! Не пожалеете. ;)

Fossil всем хорош, кроме отсутствия стандартного хостинга для него, наподобии того же github.

Во первых, chiselapp же. Во вторых – если на подобии github, то будет и все недостатки github из за которых мы и ищем альтернативу.


Почему люди не хостят свои git проекты сами? А потому что это очень сложно для поддержки. Нужны несколько веб приложении, которые устанавливаются отдельно на сервере, настраиваются отдельно и поддерживаются отдельно. По сути, каждый должен развернуть свой GitHub/GitLab, что чаще всего не оправдано.


A вот, с fossil все эти сложности отсутствуют в принципе. Запустил на сервере бинарник и все работает из коробки.

А двустороннее гейтование fossil<->Git работает? (Так чтобы, например, репа из Git прошедшая через fossil восстанавливалась 1:1 со всеми коммитами)
Если нет — то совместимость с современным миром будет нарушена, такой себе vendor lock.

Не совсем. В смысле, в fossil хранится намного больше информации чем в git. Сделать однозначное соответствие просто невозможно. Обычно делают просто зеркало на git.


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

Есть еще Gitea - маленький GitLab. Очень приятный, для чего-то небольшого в самый раз.

Поддерживаю. Очень классная и лёгкая штука.

Fossil пробовал, но слегка недопонял его концепцию с отдельным файлом БД. Непонятно, где его хранить.

… но слегка недопонял его концепцию с отдельным файлом БД. Непонятно, где его хранить.

А где угодно – у меня например есть директория "/work/Repositories" куда храню все репозитории проектов. Но это не обязательно – можно в ~/fossils или как нравится. Удобно чтобы все были в одном месте.

В копилку комментариев с автономными хостингами Git добавлю Gerrit. Используем с 12-го года, в основном довольны, нареканий мало, бесплатный. С Jenkins интегрируется штатно. Система peer review с контролем оценок и кастомизацией правил.
Специфика: git-flow и прочие подходы с толпой персональных веток на сервере — не для него. Основной метод — короткие почти безымянные цепочки коммитов поверх длительных веток (master/main/trunk, релизные ветки). Зато комментарии, например, на каждую строчку и на коммит отдельно (а не как местами можно написать только на весь pull request).
Ещё недостаток — логика кастомизации оценок делается хуками на Prolog с хитрыми правилами раскрытия — освоить ой нетривиально. (Или я отстал и сделали удобнее?)

Блин, я то думал опять Idea глючит, повисла намертво

Idea виснет от неработающего гитхаба?

Ну да, сделал pull - только перезагрузка спасла.

Это такой современный тренд - обмен по сети прямо в обработчиках UI. Причём блокирующий. В винде ещё считается признаком хорошего тона повесить системную очередь событий.

Не зря в андроид сделали NetworkOnMainThreadException. Правда, всегда можно в UI-треде крутить прогресс индикатор и ждать, пока фоновый закончится :-)

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

Наоборот, в современном мире принято засовывать не UI операции в отдельные потоки или даже процессы. Почему в Idea это не работает для данного случая — не знаю, надо разбираться.

Скажем так, софт JB не отличается хорошим техническим состоянием. Интерфейс да, вполне хороший. Но даже проект с шаблонами с всего 50cloc вешает clion только в путь.

Скажем так, софт JB не отличается хорошим техническим состоянием.

это недостоверная инфа. Раз так хаите - предлагайте альтернативу. На мой взгляд, среды от JetBrains - это на текущий момент лучшее, что есть на рынке. Разве что в vim сидеть....

VS Code весьма недурен

Может и неплохие, тут не может быть консенсуса. Но ведь ещё и тормозят, заразы. Разве нормально, например, если зажать любой символ на 5 секунд, рисоваться в редакторе он потом будет ещё секунды. И это с power save, т.е. с минимальным фоновым анализом. Неужели 8 десктопных ядер и 16 Гб памяти мало на такую простую операцию?

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

Это скорей проблема в самих плюсах — сложно их хорошо обрабатывать в реально времени из-за обилия шаблонов.

Гипотеза легко опровергается простым примером: есть CLion, есть Neovim. Оба используют для анализа кода один и тот же clangd. При этом CLion безбожно тормозит, а Neovim летает.

Из этого можно сделать только один вывод: проблема именно в CLion, с анализом плюсового кода всё в порядке.

Вы отчасти правы - "проблема" в том, что CLion полноценно парсит и резолвит код, а редакторы вроде Neovim лишь частично. Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации. А CLion собирает и обрабатывает больше информации, чтобы это все уметь.
При этом, C++ язык не простой - там для корректной покраски кода (спасибо перегруженным операторам и не только) надо полностью резолв кода запускать.
Мы в CLion постоянно оптимизируем наш парсинг, резолв, и все операции, чтобы отзывчивость редактора была вменяемой. Движок на основе Clangd у нас при этом сильно отличается от мастера LLVM репозитория - там множество наших оптимизаций и куча дополнительных возможностей, которые мы не апстримим.
CLion, пока к сожалению, и правда на многих примерах бывает тормозит еще - мы пока не везде извели старый языковой движок, который уже решено не поддерживать далее. На Clangd еще при этом не все работает. Но я надеюсь, что наша постоянная работа в этом направлении все же не остается совсем незамеченной)
А с конкретными "тормозами" лучше приходите в трекер или саппорт, посмотрим на конкретный CPU снэпшот и раскопаем конкретную проблему. Может, воркэраунд какой-то сразу подскажем.

Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации.

Я использую плагин coc.nvim и у меня работают и переименование символа по всему проекту, и переход к определению/реализации, раскиданным по разным файлам.


Но вообще рад слышать, что работа ведётся. Хотя меня кроме тормозов останавливает ещё и вот этот (ссылка) 9-летний (!) мажорный (!) баг в vim плагине.

Про IDEA Vim - пинганула команду, у них, я так понимаю, какие-то варианты там есть, но четкого плана нет. Можно оставлять комментарии и пожелания в тикете, если еще не успели.

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

Проблемы наблюдались в течение часа. После этого никаких ограничений нет.

У меня push прошёл, а в веб зайти уже не получилось.

А сейчас зашёл в веб-интерфейс, а в нём этого запушенного коммита нет.

Примечательно, что впервые за несколько лет, на гитхабе сменился SSH ключ сервера:


It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.

уж несколько недель как.

Мы в проектах nodejs юзаем Verdaccio, удобно и добавляет надёжности системе от таких вот ситуаций

ля все налетели на чужие проблемы , за своими проектами смотрите

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

Сейчас всё нормально, зайти могу

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости