Платформа совместной разработки Bitbucket прекращает (https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...) поддержку системы управления исходными текстами Mercurial в пользу Git. Напомним, что изначально сервис Bitbucket ориентировался только на Mercurial, но начиная с 2011 года также стал предоставлять (https://www.opennet.ru/opennews/art.shtml?num=31935) поддержку Git. Отмечается, что Bitbucket эволюционирует из инструментария для управления версиями в платформу для полного управления циклом разработки ПО, нацеленной на разработчиков, придерживающихся парадигме DevOps.
В нынешнем году развитие Bitbucket будет сконцентрировано в области
расширения средств автоматизации и совместной разработки, которые помогут упростить планирование, кодирование и развёртывание проектов. Поддержка двух систем управления версиями тормозит и усложняет реализацию намеченных планов, поэтому решено сосредоточить всё внимание только на Git и полностью отказаться от Mercurial. Git выбран как более актуальный, функциональный и востребованный проект.По данным опроса Stack Overflow почти 90% разработчиков предпочитают Git, а Mercurial используют всего 3% опрошенных. Подобную тенденцию подтверждает и внутренняя статистика Bitbucket, которая также показывает неуклонное снижение популярности Mercurial - из новых пользователей Mercurial в Bitbucket выбирают менее 1%. При этом, Mercurial продолжает использоваться для разработки проектов Mozilla, OpenOffice.org, OpenSolaris, OpenJDK, Nginx, Xine и W3C.
1 февраля 2020 года в Bitbucket будет запрещено создание новых репозиторев Mercurial, а 1 июня 2020 года будет отключена вся связанная с Mercurial функциональность, в том числе убраны специфичные для Mercurial API, а также удалены все репозитории Mercurial. Пользователям рекомендуется мигрировать на Git для чего предложены утилиты (https://community.atlassian.com/t5/Bitbucket-articles/What-t...) для конвертирования репозиториев. В случае, если разработчики не желают менять привычный инструментарий, предлагается перейти на другие (https://www.mercurial-scm.org/wiki/MercurialHosting) хостинги открытого кода. Например, поддержка Mercurial предоставляется в SourceForge (https://sourceforge.net/), Mozdev (https://www.mozdev.org/) и Savannah (https://savannah.gnu.org/).URL: https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...
Новость: https://www.opennet.ru/opennews/art.shtml?num=51323
Ну если они хотят прикручивать к сервису новые фичи, которые тормозятся меркуриалом, так не прикручивали бы их к нему. В гите пусть будут, а меркуриал по функциональности пусть будет заморожен.Если меркуриалом никто не пользуется и репозиториев меньше одного процента, то что им стоит просто их поддерживать работающими? Опять удалят здоровенный пласт кода с историей и на форумах будут висеть ссылки, которые ведут в никуда.
Стоит дорого. Тестирование, просто учёт при разработке, реакции на жалобы, проблемы с совместимостью кода, риски безопасности и так далее.
Тогда отправили бы в Apache-могильник, да и все или на откуп сообществу выкинули
> Тогда отправили бы в Apache-могильник, да и все или на откуп сообществу
> выкинулиТы путаешь: то оперсорс-могильниик, а тут проприертраный.
Закрыли закрытое в закрытый могильник. Панимаишь? Общественно полезная услуга...
> Подобную тенденцию подтверждает и…Нездорово, когда из-за веяний моды и беспорядочной суетливой беготни обезьянок люди бросают всё, что делали годами, а не пытаются сделать свой проект лучше конкурентов. Сами без принуждения дают козыри в руки будущим монополиям, а после будут удивляться, как же так всё получилось.
Ну причем тут мода? Очевидно же что в борьбе HG и GIT лидер опеределился достаточно давно. Единственная ошибка, которую они сделали - это объявление данной новости без подготовки, не предоставив удобного инструмента или инструкции по конвертации репозиториев.
> Ну причем тут мода?при том что обезьянкам следовало бы продолжить твою фразу: "очевидно же, что в борьбе github и gitlab лидер определился достаточно давно, а битбакет - свалка брошенных проектов мертвых лавочек, и ненужен вообще никому ровно так же как его три процента меркуриалов". И через пару лет придет к закономерному банкротству.
Потому что два гитлаба точно не нужны. Точно так же как не нужны обезьянкам vcs отличные от той, в которой они "освоили" push и pull.
>> Ну причем тут мода?
> при том что обезьянкам следовало бы продолжить твою фразу: "очевидно же, что
> в борьбе github и gitlab
>лидер
>мертвых лавочек
>к закономерному банкротству.
> Потому что два гитлаба точно не нужны.А вот и господоин экспент по олимпийской борьбе косла с озлом со своим принципиальным и однозначным....
..."микрософт побеждает".
То есть две открытых софтины и два конкурирующих коммерческих продукта (которые продаются и деньги приносят) не различаем?
а чего их различать? Вам лишь бы на халяву, все с лопаты слопаете.
Можно подумать, освоение push/pull во всех где-либо используемых VCS сделает из обезъяны человека.
> Можно подумать, освоение push/pull во всех где-либо используемых VCS сделает из обезъяны
> человека.нет, конечно. Но они ж и этого - тоже не могут.
Уже больше десятка лет git - отраслевой стандарт, а у вас всё мода и мода.
Весь мир мода, а люди в нем хипсторы.Во так вот, братюня. Один я не хипстор, один я на белом коне.
> Один я не хипстор, один я на белом коне.Деление на ноль.
Mueller English-Russian Dictionary (mueller7)
hipster
[ˈhıpstə] _n. _разг. человек, презирающий условности, хипстер, битник
Хотя... может и само слово противоречивое:Новый Большой англо-русский словарь (magus)
hipster
1> _сл. хипстер, битник; человек, презирающий условности
2> любитель поп-музыки
У крупных компаний, которые ворочат тоннами кода. Для небольших проектов он бессмысленен. Думаю 90% использующих git заучили две команды и более не знают, а потом плюются от ловли ахтунгов.
> Для небольших проектов он бессмысленен.Глупости какие, как раз наоборот. Если внесение патчей в проект требует изучения ещё одной новой нескучной DVCS, то вносить патчи в этот проект не будут.
если ты не можешь осилить ДАЖЕ mercurial - тебе не надо вносить патчи в прекрасный CoC.md - тебе надо пойти в макдак работать.
Поддерживаю полностью!
Тем более, что hg значительно проще git-а по освоению таких простых вещей. Если надо принести патч, мерж-реквест/пулл-реквест, то в данном случае ничего сложного нет и изучать тут просто нечего, но если ты не способен даже на такое ничтожное усилие, то возникает резонный вопрос - каков вклад ты можешь привнести, кроме правки всяких CoC.md и README.md?И да, если уж отказываетесь, то подготовьте публику. Скажите, что мол, не справились, не смогли осилить, jpython не для нас и мы не умеем в апи mercurial. Извиняйте. Вот вам инструменты для конвертации репозиториев, вот так-то ими пользоваться. Давайте мы вам поможем адаптировать уже размещённый у нас проект к громоздкому git-у. Так-то можно настроить ваши CI/CD процессы (если прикручено к репозиторию) - это для такого-то CI, это для другого-то CI, это - для третьего и тд.
Но какбэ подумайте сами: послезавтра они скажут, что вот у нас есть поддержка perforce, а git мы сворачиваем. Это к вопросу о предоставляемом сервисе - расширять функции - это одно, сворачивать функции и вводить плату за "если хочешь больше" - это другое, а просто упразднять - это уже имиджевый вопрос. Какова надёжность такого сервиса? Вот ты разместил там проект, затратил деньги и время, а они такие: ваши операционные расходы должны вырасти в связи с нашей некомпетентностью. Ну и что? я от них свалю и они лишатся платного клиента, так как они в лице людей, готовых платить, уже не предоставляют надёжный сервис, ибо просто-напросто сегодня сервис есть, а завтра - досвидули.
> Тем более, что hg значительно проще git-а по освоению таких простых вещей.ну как он может быть "проще", если чувак делает pull, а файлики - не обновились? Это решительно невозможно понять (тем более что push работает как нада!) тем более - комитеру README.md
вот они и не понимают, вполне искренне.
И не, пефорса не взлетит - это ж деньги платить надо, этого тем более никто не любит - ни девелоперы, ни тем более эфехтивные. Будет только один git - под мудрым руководством microsoft, затобесплатно.
Кстати, с нескучным интерфейсом к svn (понятно, после первого же svn mv или cp вся история внезапно накроется, но кому она нужна)
а почему пул должен что-то менять локально? мне это поведение наоборот видится более логичным. потом делаешь update в нужную ревизию, если надо(если не надо сейчас - можно просто посмотреть с чем предстоит мержиться) а у гита наоборот из-за таких вот слишком высокоуровневых команд-комбайнов приходится оборачивать и велосипедить алиасы, тогда как можно было сделать несколько простых низкоуровневых и БЕЗОПАСНЫХ и потом собирать комбинировать их
меркуриал значительно проще так как у него не торчит наружу кучка кишок и команды очень грамотно побиты и делают только то что заявляют
> у гита наоборот из-за таких вот слишком высокоуровневых команд-комбайнов приходится оборачивать и велосипедить алиасы, тогда как можно было сделать несколько простых низкоуровневыхУ вас вообще-то уже есть куча plumbing-команд из коробки. Ну, да, без защиты от дурака, извините, но знатоки внутренностей гита и не ждут, что остальные возьмут и резко бросятся их использовать, а на высокоуровневые им уже плевать.
дык - потому что они так привыкли!
хренак-хренак-хренак,комит,ой что там-кто там? pull...уп-с, непрошенный мерж.
Тимлиииииид!? Как мне откатить репо ?!(не, fetch-то у гита есть, но типикал разработчик либо не вспомнит, либо запутается)
А тебя не смущает, что чтобы запушить, ещё закоммитить для начала надо?
меня ничего не смущает - я умею пользоваться hg. Смущает - осиливших две команды и еще вот это "тимлид, ась - как отменить этот дурацкий автомерж, я забыл как ты вчера объяснял".но других разработчиков, к сожалению, нет, и других админов, подозреваю, уже тоже.
Потому что hg pull - это примерно то же, что git fetch.И делать сначала fetch и смотреть "а что там" - это в целом хорошая практика. А то намержит, а нафига мне мердж-коммиты? (Не, я знаю про --rebase, у самого в gitconfig стоит [pull] rebase = true. Но большинство не знают).
> Потому что hg pull - это примерно то же, что git fetch.только про последний знают единицы. Как и про git pull --no-commit --ff-only
> И делать сначала fetch и смотреть "а что там" - это в целом хорошая практика.
на самом деле это херовая практика. В смысле - опять самому делать работу за тyпого робота.
> Не, я знаю про --rebase
я могу не хотеть rebase (например, потому что знаю, что не получится). По хорошему - надо остановить мерж и _спросить_, точно ли мне оно надо. Но это для "порежьте по три строчки и заверните каждую в салфеточку" не требуется, а они и есть авторы.
Поэтому приходится каждый раз вручную. И, заметим, полноценного аналога hg in тоже нет (который ничего не фетчит, а просто показывает - поменялось ли и что именно, git fetch ни разу не замена)
Когда я знаю, что получится, я хочу rebase. А это 95% случаев.А когда у меня есть подозрения, что не получится, я хочу посмотреть, а потом принять решение, что с этим делать. Понятно, что можно глянуть и в вебморде, но мне удобнее в консоли.
hg in - да, его не хватает, но с фетчем можно жить.
А зачем осиливать меркуриал, если во всех нормальных проектах Git?
> Для небольших проектов он бессмысленен.Правильно. Для небольших проектов идеален fossil. А hg пытался конкурировать с git именно на фоне больших проектов.
P.S. Для очень больших проектов git тоже плохо подходит - приходится вставлять кучу костылей.
ms уже навставляла - костылей на больную сороконожку хватит. И ничего, жрут.
Костылями мс никто пользоваться не заставляет, это вообще отдельный проект на дотнете
> Для небольших проектов идеален fossil.Это тот комбайн со встроенным веб-сервером, который используют только Tcl/Tk и сам fossil?
это тот комбайн со встроенным _работающим_ вебсервером (в отличие от невменяемой хрени, встроенной в git чтоб было что выбросить и не сильно лучшей, встроенной в пихон, который встроен в hg...или вернее hg в него встроен ;) который используется _в_том_числе_ tcl и sqlite, помимо мильена мелких проектов, которые могут, умеют, и совершенно не видят смысла в привлечении "разработчиков cock.md", осиливших единственно-верную площадку.(прикол там не столько в вебсервере, сколько в том что этот вебсервер умеет - а он умеет и трекер, и вику, и все что положено)
все в одном, прямо как systemd! :-)
> все в одном, прямо как systemd! :-)в отличие от системды - никто тебе не мешает пользоваться только vcs. Правда, вику и трекер и их связку с фоссилом придется написать самому - никто из известных мне - не поддерживает. Полагаю, именно потому, что не больно-то и хотелось, и так сойдет.
Да с системдой примерно так же, можно скомпилить самый минимум, только а что мне с этим делать :-)Вообще задумка у fossil интересная, но на практике не пробовал, уж слишком отличается flow, надо менять привычки радикально.
> Да с системдой примерно так же, можно скомпилить самый минимум, толькопользы от такого минимума - никакой.
Я пробовал (flow тут ближе к svn, если специально автосинхрилку не выключить), но под мои задачи больше подходит таки svn, а без встроенного трекера я переживу.
В команде без rebase и возможно cherry-pick не обойтись (это минимум для рядового PR-щика).
VCS может быть бессмыслен только если только один лично работаешь и никогда не ошибаешься (иначе надо отслеживать историю, чтобы понять, как ты там или здесь наворотил).
>Уже больше десятка лет git - отраслевой стандарт, а у вас всё мода и мода.Когда ту же логику применяют к МСофису и его форматам или винде на ПК, к фотошопу или корелу, то у местной аудитории почему-то бомбит.
ты этого, не того, а то мы тебя...
> Когда ту же логику применяют к МСофису и его форматамВы сейчас про пропихнутый стандарт OOXML обложенный патентами майкрософта? Или про сам проприетарный MS Office?
Бомбит потому что монополиями навязана дрянь
> Бомбит потому что монополиями навязана дряньКакая разница что навязано? Отсутствие альтернативы — не есть хорошо.
И да, МСО куда как удобнее ОО и ЛО. Но это уже вопрос вкусов.
А где тут отсутствие альтернативы? Очередной проприетарный сервис что-то там выпилил? И что?
> А где тут отсутствие альтернативы? Очередной проприетарный сервис что-то там выпилил? И
> что?а что, еще кто-то был или хотя бы - остался? Может, еще и не проприетарный?
rhodecode ? Так там русские, кажись...
Не проприетарный как был один savannah.gnu.org так и остался.UI, там, конечно, тот еще, это да. И качество кода сомнительное. Ну что ж поделать. Я бы может и написал нормальное, но с их принципом "должно работать без JS" даже начинать не хочется. (Вообще не понимаю, в чем проблема с JS, если он опенсорсный, у Столлмана в Lynx-е не работает?).
> (Вообще не понимаю, в чем проблема с JS, если он опенсорсный, у
> Столлмана в Lynx-е не работает?).У Столлмана бот, пересылающий страницы в почту. Но даже без этого проблема в том, что стоит допустить молодёжь до интерфейсов, как вместо простых страниц а-ля опеннет получаются тормозные монстры, бесполезно для пользователя жрущие память своими Virtual DOM и реактивными компонентами.
Их просто надо уметь готовить. Если аккуратно ручками выпиливать, а не тащить тонны хлама из npm - ниче не жрет. Ну, то есть, конечно, небольшой оверхед есть, но отсутствием релоада и ререндера всей страницы на каждый пук вполне себе компенсируется, а юзабельность куда лучше.
> Их просто надо уметь готовить. Если аккуратно ручками выпиливать, а не тащить
> тонны хлама из npm - ниче не жрет. Ну, то есть,только закончен проект будет - примерно никогда.
> конечно, небольшой оверхед есть, но отсутствием релоада и ререндера всей страницы
> на каждый пук вполне себе компенсируется, а юзабельность куда лучше.что-то мне подсказывает, что браузеру совершенно все равно, и релоад целиком страницы опеннета занимает меньшее время, чем нажатие волшебной кнопочки в модном интерфейсе гитляпа
>> (Вообще не понимаю, в чем проблема с JS, если он опенсорсный, у
>> Столлмана в Lynx-е не работает?).
> У Столлмана бот, пересылающий страницы в почту. Но даже без этого проблема
> в том, что стоит допустить молодёжь до интерфейсов, как вместо простых
> страниц а-ля опеннет получаются тормозные монстры, бесполезно для пользователя жрущие
> память своими Virtual DOM и реактивными компонентами.так, на минуточку - напомню, у hg веточки в дереве - рисуются canvas. ;-)
Если бы мсофис работал на линуксе, то многие пользовались бы и не морщились (кто-то тайком, продолжая публично клясть мелкомягких)
> Если бы мсофис работал на линуксе, то многие пользовались бы и неа чего, не? А, ну да, вам же вайн обещали доломать...
Git это СПО и поэтому к нему нормальное отношение как к стандарту и вообще, в отличие от матёрой проприетарщины.
> Git это СПО и поэтому к нему нормальное отношение как к стандарту и вообще, в отличие от матёрой проприетарщины.Т.е. вопрос не в объективных параметрах, а в идеологии открытости. Но это не ко мне, а к сектантам.
Нет никакой суеты, просто HG это неудачный проект и от него начали отказываться довольно давно.
Пояснений о неудачности мы конечно же не дождёмся.
А ссылку на RussiaToday тебе не нужно?
не, давай сразу на усраин тумороу. Ой они ж закрылись чз день после открытия
> Пояснений о неудачности мы конечно же не дождёмся.На одном из крупнейших сервисов, предоставляющих HG в качестве опции, доля его использования меньше процента. Как ещё пояснения тебе нужны?
Для начала посчитали бы тогда уж и число пользователей, использующие ВСЕ возможности их гуйни. А то выяснится, что кроме git pull/push используется в 99% случаев.
"кроме" лишнее
Таким пользователям абсолютно похрену, что происходит внутри, поэтому компаниям, осблуживающим репозитории, выгодно стандартизироваться на том, что предпочитает большинство, чем поддерживать кучу разных VCS
А что тут пояснять, если даже Python с hg свалил
HG не первый день существует ... ну ладно. Авторы чрезмерно упоролись модульностью и слепым академическим подходом в дизайне веток.Ранние версии HG нужно было чуть ли не руками собирать в поисках нужных расширений и подключением в конфиге тривиальных фич типа подсветки синтаксиса. В Git всё всегда работало из коробки и в единственном виде, т.е. не нужно выбирать желаемую функциональность из N расширений, каждое из которых решает задачу частично.
Со временем наркоманию с модульностью немного поправили двигаясь в сторну коробочного решения, но из-за упёртости разработчиков по некоторым вопросам вроде нужности staging area (git index), удобство работы с продвинутыми фичами осталось на порядки хуже по сравнению с Git.
Наделали несколько видов веток так, что пользователю нужно заранее планировать работу с репозиторием. И это в DVCS позиционирующий себя для болванчиков. Git с тривиальной архитектурой веток оказался намного гибче и позволяет пересмотреть стратегию использования веток в процессе работы.
Какие бы фантазии не были у фанатов Mercurial, но Git тупо проще и удобней.
Вообще в меркуриале есть mq, который заменяет кучу фич гита. Но его настолько никто не осилил, что даже задепрекейтили. Хотя там ничего сложного, если в голове немножко мозгов есть.
Вот MQ постоянно пользуюсь, хотя при необходимости навереное мог бы как-то и выкрутится другим функционалом hg (в т.ч. другими расширениями).
Но уж больно удобные эти патчи).
По факту эти патчи у меня являются серией из нескольких staging-area.
Очень часто происходит что-то вроде (мой личный flow):
1. Интересно, если в проекте сделать то-то и так-то, как оно будет. Меняю исходники.
2. Более или менее завершив изменения сохраняю их ввиде патча mq, скажем "experimental ..."
3. Если всё получается норм, то продолжаю так появляются условные "experimental ... 2" и т.д. О Порядке и группировке функционала в патчах не забочусь (дабы не спугнуть вдохновение).
4. Если что-то не получается или оказывается слишком сложным или вдохновение кончается, то сохраняю последний патч и "отрываю" все заплатки
5. Занимаюсь другими вещами, возможно комича другое
6. Когда снова появляется желание поэксперементировать, то применяю эту серию патчей и делаю еще что-то
7. Когда дело доходит до работоспособности, то начинаю думать о порядке вывода этого в прод.
8. Группирую проделанную работу в отдельные комиты. Накатываю/откатываю/схлопываю/сортирую и создаю новые патчи.
9. В любой момент времени могу остановиться и переключиться на другие задачи
10. Когда какие-то патчи уже готовы, то либо всю серию либо часть (обычно подготовительный функционал) финализирую/пушу и мержу в бой.Кроме того довольно много разного рода тестовых патчей, временных для локального запуска и т.д.
Иногда из старого патча нужна бывает только часть кода. Иногда два разных эксперимента в итоге сливаются в один. Не видел иного инструмента, который позволял бы такое же и с такой простотой.Причем вся работа идёт в одном локальном репо проекта.
Внимание! Обнаружен редкий вид - программист, который умеет пользоваться Mercurial. Требую немедленно занести в красную книгу!
Не, щас, конечно, тут объяснят, как это все делать в git через staging, stash, временные ветки, rebase и такую-то матерь, я и сам так делаю (куда от Гита ныне денешься), привык и не жалуюсь, но вспомнил, насколько же это все было удобнее в ртути и аж слезу чуть не пустил. :-)
> Вообще в меркуриале есть mq, который заменяет кучу фич гита. Но его
> настолько никто не осилил, что даже задепрекейтили. Хотя там ничего сложного,просто уже есть гит.
То есть если тебе нужен mq- можно спокойно гитом пользоваться. А тем кому hg - он как-то не особенно зашел.
> Вообще в меркуриале есть mq, который заменяет кучу фич гитаMq это уныние, грусть и печаль если рассматривать как замену некоторым фичам Git - решение неполноценное и с ужасным интерфейсом. Многое в этот ужас вносит отсутствие staging area в HG.
> Но его настолько никто не осилил, что даже задепрекейтили.
Неужели. Давай посмотрим что про него думают разработчики:
> The problems with MQ is that it introduces a new concept, the patch, which is essentially a commit that doesn't know merge logic and (2) many of its operations (qrefresh, qfold, qdelete) do not produce any backups, so it's easy to lose work
Т.е. эта фича прикручена костылём и не по феншую. Случай наглядно демонстрирует зацикленность дизайнеров HG на неких минорных деталях и полное отсутствие целостного представления сочетания этих деталей в одном продукте.
Ну и правильно. Если говорить языком аналогий, если Бог написал Вселенную, то написал он ее на Си, и использовал при этом Гит.
На лиспе. И Бог не использовал системы контроля версий. Он говорил программу семь дней, и Вселенная заработала.
Не нужна система контроля версий для проекта, который всего 7 дней длился и который потом никто не будет поддерживать.
7 (6) дней это только компиляция.
а может, таки, uptime?
6 дней кодил, на 7-й запустил
"Ну как бы да, но если честно, по большей части все было наспех склепано на Перле": https://www.xkcd.com/224/
То-то говнокод такой получился.
> На лиспе. И Бог не использовал системы контроля версий.Там у них сроки горели, так что...
"[Last night I drifted off while reading a lisp book. ...]
Honestly, we hacked most of it together with Perl."https://www.xkcd.com/224/
https://xkcd.ru/224/
https://www.explainxkcd.com/wiki/index.php/224:_Lisp
>если Бог написал Вселенную, то написал он ее на Си, и использовал при этом ГитМожет, Гит и исползовал, но написал он её на Плюсах.
Он сразу придумал в машинных кодах, и все что теперь происходит - его мысли-потоки.
тогда бы оно сегфолтилось каждую субботу.Так что да, скорее всего он думал прямо в кодах - он-то - Бог, он-то могет. (я,правда, вполне в вещественном мире запрещенное-на-опеннете-слово видел, который музычку в кодах на бк-0010 писал, не то чтобы сильно напрягаясь, ну мало ли - Б-жье откровение осенило, бывает)
Правда, примерно в 3760м был рефакторинг, как обычно, половина юзеров так от него расстроилась, что предпочла сидеть на прежней версии, не смотря на плохую совместимость, а половина второй половины запилила какой-то форк...
Еще со времен C VS Pascal было понятно что из двух вариантов "сообществом" будет выбран худший.
> Еще со времен C VS Pascal было понятно что из двух вариантов
> "сообществом" будет выбран худший.ну вроде ж дельфи - сдохла?!
"сообществу будет выбран" - так правильно.
сам hg не пользуюсь, но ИМХО git зажился.
А Пастернака читал?
И Bitbucket станет резко бесполезным.
Не думаю, что они это просто так решили. Им там виднее, что наиболее востребовано их коммерческими клиентами, и почему эти клиенты платят именно им, а не конкурентам.Но жаль. Меркуриал мне всегда нравился больше Гита: он проще, понятнее и удобнее.
угу, все дЭффективные так думают. А потом улетают на золотых парашутиках, желая уволенным горе-разработчикам приятного полета.> Но жаль. Меркуриал мне всегда нравился больше Гита: он проще, понятнее и удобнее.
но битбакета - ни разу не жаль, он всегда был г-но.
ms'овского codeplex вот немножко жаль. Ну там понятно -индусы ж не умеют никакой hg, зачем он им.
> ms'овского codeplex вот немножко жаль.Да-да, не сдерживася. Поплачь.
Битбакет берётся в комплекте со всеми остальными атлассиановскими сервисами. Он, пожалуй, гитхаб переживёт.
современным разработчикам эти его "сервисы" нихрена непонятны и неудобны (в общем-то и по факту оно так). Они хотеть гитхаб!
Ну так там, где атлассиан деньги зарабатывает, решают не разработчики,а менеджеры. Которые хотят взять всё сразу в одном месте, интегрированное и чтобы администрировал кто-то другой. Кстати, разработчики там обычно хотя того же.Открытым проектам надо другое, ну так они ничего на битбакете и так не забывали в основном.
дык, гитхап и гитшлак предоставляют платные услуги, с великим удовольствием.Прикол атласиана в его специфических других продуктах - которые как раз малоосмысленны, если ты не можешь их подпилить под местные задачи. А это автоматически означает что админов таки придется нанять, причем со специальными умениями (у нас когда-то цельный отдел был, прям как для 1С какой). А ведь гитшлакCE развернет тебе любой девляпс, бешплатна!
мне git-only напоминает windows-only - не только пользоваться самим, но и всячески его насаждать и создавать проблемы всем остальным: патамушта у нас единственно правильный путьпользуюсь и git, и hg, и fossil. и даже cvs :) но только как фетчилкой
> всячески его насаждать и создавать проблемы всем остальным: патамушта у нас единственно правильный путьPulseaudio, systemd.
А смысл? Если гит уже знаешь - то можно им для всего пользоваться. В отличие от винды, где проблема не в том, что в ней уметь работать надо, а в том, что она кучу проблем создаёт и денег стоит.Если не знаешь - то даже если он и посложнее прочего то всё равно ментальная нагрузка по его освоению копеечная по сравнению с тем, что ты собрался в версионник класть.
Ты что, вантузоид? Нужно пользоваться одновременно и лопатой, и палкой-копалкой из каменного века.
> Ты что, вантузоид? Нужно пользоваться одновременно и лопатой, и палкой-копалкой из каменного века.Судя по регулярно-яростному упоминанию "вантузоидов" и сравнению ртути с палкой-копалкой, кое-кто у нас уже (почти) аж три месяца "не вантузоид", да?
> Судя по регулярно-яростному упоминанию "вантузоидов" и сравнению ртути с палкой-копалкой, кое-кто у нас уже (почти) аж три месяца "не вантузоид", да?Это да, вон некий "б.б" при упоминании гита сразу перешел в поражающие всякое воображение аналогии с вантузоидами:
> Сообщение от б.б. (?), 21-Авг-19, 03:25
> мне git-only напоминает windows-onlyЖдем от него ответки по поводу того, что он "три месяца не вантузоид".
Очнись, они ничего не нсаждают, а тупо минимизируют свои расходы за счет удаления малоиспользуемой фичи.
> мне git-only напоминает systemd/pulseaudio-only - не только пользоваться самим, но и всячески
> его насаждать и создавать проблемы всем остальным: патамушта у нас единственно правильный путьпофиксил, так понятнее.
То есть они их тупо удалят за место того чтобы "сконвертировать" в git (хоть и без истории но хотя бы с ветками)? Лол. Позор.
Нафиг мне репозиторий без истории? Я с тем же успехом качну его в виде архива. Вопрос в том, что могут быть проекты, авторы которых их забросили и не будут заморачиваться их конвертировать.
разве нет чего-то типа git-hg? даже для свн такое есть, значит и для меркуриала тоже должною
есть
https://hg-git.github.io/
> разве нет чего-то типа git-hg? даже для свн такое естьты этим "таким" пользоваться-то пробовал?
> значит и для меркуриала тоже должною
только пользы от него будет еще меньше.
(hg-git это в другую сторону, кстати, угадайте - где у него репо, и в каком формате ;-)
Думаю, они посмотрели, сколько там заброшенных mercurial-репозиториев (еще с времен, когда у них поддержки гита не было даже в планах и прикинули, сколько бабла сэкономят.Технически-то сконвертировать особой проблемы нет.
это какой-то не дэффективно-менеджерский подход.Если бы они посмотрели сколько там ВСЕГО дохлых репозиториев - то мигрировали бы, наоборот, на hg. Бабла бы сэкономилось гораздо больше.
Ну вот такие вот менеджеры в Атлассиане.
Я не вижу другого объяснения отсутствию автоконверта (или хотя бы кнопочки "сконверти-ка мне тут все").
Разработчики битбакета напоминают мне тех кто пишет cp1252-only софт, который не умеет в нормальную поддержку языков и вечно показывает каракули, как то было 20 лет назад.Когда закрыли ГуглКод я в битбаките создал issue. По типа вашим downloads не хватает тегов. Вот история:
>>> Thanks for raising this issue. I've added this to our backlog and we'll look into this at some point. Cheers, Brian 2014-01-31
>>> Marcus Bertrand staff marked as minor 2014-02-10
>>> Zachary Davis Account Deactivated Removing component: usability (automated comment) 2014-02-21
>>> Atlassian Bitbucket changed status to closed This issue has been closed due to inactivity. If you continue to see problems, please reopen or create a new issue. 2016-04-152 года карл они не решили этот вопрос!
Что за мода пошла - закрывать за давностью? Типа - "ну и хрен с ним с багом, может не заметит больше никто, зато у нас багтрекер чистый"?
Позиция «жили мы тыщу лет без вашего *** — и ещё тыщу проживём» встречается довольно часто.
ubuntu way!
Нормальная мода для коммерческой конторы, которой практический результат нужен. Если за энное время никто к low priority багу не добавился - значит он и правда никого не интересует. Закрыли - менеджер не тратит время на его анализ, более корректная статистика по багам и вообще мусора чуть меньше.
> Нормальная мода для коммерческой конторы, которой практический результат не нужен.поправил, не благодари.
Любой баг надо объявить low priority и подождать пару лет - глядишь, юзер привыкнет обходиться костылями, или свалит нах со своими тремя копейками.
А потом его закрыть, как "неактивный".
Может ты с тех пор свалил с битбакета и фича больше никому не нужна?
это ж Atlassian, они баг репорты и уж тем более фич реквесты всегда по несколько лет рассматривают
Тут лучше вспомнить многолетний issue с группировкой/тегированием/либо каким-то другим методом организации реп. И кстати непофиксили
Невразумительно чуток.Не последнюю роль сыграло достижение сервисом планки в 10 млн. пользователей. Далее, компания видит git как самую популярную платформу (90%) управления версиями, в то время как mercurial -- наименее популярная (3%). На самом сервисе использование mercurial неуклонно падает (видимо, имеется в виду процент действий), и доля новых пользователей сервиса, выбирающих, mercurial, упала ниже 1%.
То есть вопрос, как всегда, в деньгах.
Далее, Компания обещает поддержать преобразование репозиториев mercurial в формат git.
Очень неудачная фраза:
> Отмечается, что теперь Bitbucket эволюционирует из инструментария для управления версиями в платформу для полного управления циклом разработки ПО, нацеленной на разработчиков, придерживающихся парадигме DevOpsСобственно DevOps здесь ни при чём. Речь о том, что Bitbucket
за время взлёта популярности DevOps...превратился из инструмента, способного лишь управлять версиями ПО, в средство управления полным циклом разработки ПО [термин стандартный; кстати, ИСО 12207].
>То есть вопрос, как всегда, в деньгах.Ви ховорите так, как будто это плохо...
Не то, чтобы я много пользовался bb, но там хостится немало проектов.
Ситуация с git на самом деле плачевная. Хотя сам проект очень важный и нужный. Обычная проблема человечества, когда большинство начинают считать, что "всё уже придумано и всё уже решено".
Раньше было какое-то обсуждение и обдумывание того как лучше вести проект, как он отражает реальный порядок, как проще его потом суппортить и т.д. Сейчас же все так или иначе должно ложиться на gh/gl/bb-flow. Раньше было сравнение централизации и децентрализации, разного рода интеграции в VCS issue трекеров. Сейчас фактически вернулись к централизации. А локальная история стала чем-то вроде кэша.
Да код можно склонировать с историей, но без описания мерджей или ссылок на issue она почти ничего не дает.
Во времена SVN мало кто пользовался для annotate/blame для разбора откуда это попало (по сети долго запрашивалось). Сейчас в git получается быстро, но надо еще разобраться в какой ветке и в рамках чего это делалось, сам git это никак не покажет, даже имени ветки не будет. Благо есть централизованная система где всё раскладывается в описания мерджей.Итого раньше всё было централизовано и мало возможностей (либо возможности с тормозами). DVCS сняли многие ограничения, но по факту всех снова вернули к централизации. Форкнуться легко, но форк как правило на той же площадке.
Как принято в git pull это и получение и обновление (fetch делают редко), так и многие комитят и сразу пушат. Если что-то не так, то делают новую ветку и вручную переносят изменения из старой в новую.
Возможно 90% пользователей git даже и не представляют как сделать мерж локально.Пока есть проекты вроде hg развивается и git, если они отойдут, то скоро думаю всех мягко пересадят на какие-то обрезанные версии возможно интегрированные в IDE, которые работают только с конкретным хостингом (типа легче и удобнее) там уж не важно будет какая по факту VCS используется. Могут разрешить клонирование только при регистрации (а так только тарболы). И прочее, прочее...
> Сейчас в git получается быстро, но надо еще разобраться в какой ветке и в рамках чего это делалосьТут вопрос исключительно соглашений в рамках каждого проекта.
У нас (конторский Gerrit/Redmine/Jenkins/Proxmox/чего там ещё девопсы накрутили) коммит невозможно запушить на ревью без тега Redmine: <# задачи> или Redmine-Fix: <# задачи>. Ну и Change-Id: , естественно.
Соответственно, видна не только причина возникновения того или иного изменения, но и то, как автор, при помощи товарищей и их въедливых комментариев, дошел до именно такой реализации.
Так что, все делается, вопрос в стандартизации и обучении персонала этим практикам.
> Так что, все делается, вопрос в стандартизации и обучении персонала этим практикам.вопрос в подборе персонала, желающего работать мартышкой.
Ручное распихивание в каждый ерундовый комит номера задачи - это именно мартышачья работа.А потом удивляемся результатам... или, вернее, уже не удивляемся совсем.
> Ручное распихивание в каждый ерундовый комит номера задачЧерез хуки, сэр, через хуки
> Ручное распихивание в каждый ерундовый комит номера задачиПочему ручное?
git config commit.template
git config alias.xxxxx список нужных опций и командЕсли не распихивать эту "ненужную" информацию, довольно трудно потом понять зачем коммит нужен был.
если вместо вменяемых описаний ченджсета вдолбленная привычка пихать бессмысленный номерок - оно так и будет.Если вдолблена, наоборот, привычка описывать смысл и назначение изменений...да нет, вы шутите, нет таких разработчиков.
госспаде пох, всем все понятно, там не только номерок. На нормальных ревью левые дескрипшны не пройдут, и через пару подзатыльников все работают адекватно согласно принятым в команде правилам. А вот если чел такой упертый, как ты, то тут уж ничего не исправишь, прощай
Это то понятно, что можно и даже нужно.
Но ведь это уже вынужденная практика. Так можно было бы и время комита, и автора тоже хранить в форматированном message. Да и обычно, если пришлось делать такую проверку на автомате, то наверняка теперь куча комитов где в описании только эти циферки, либо не сильно лучшие "Some work on #12345".
В любом случае разбор истории без этих "Gerrit/Redmine/Jenkins/Proxmox/чего там ещё девопсы накрутили" становится не возможен. Как следствие всё будет опять на централизованном сервере и возможно даже только в вебе. И чем это существенно отличается от SVN?
ИМХО, тренд на децентрализацию завернули накидав сообществу косточек.
я и говорю - типовая обезьянья работа, вручную делать связки репо с трекинговой системой - в каждом комите. Я прямо мечтал о такой, ага.> И чем это существенно отличается от SVN?
для большинства разработчиков - набором непонятных заклинаний. Кстати, у svn их было меньше.
Осмысленность коммит мессаджей (а так же PR, багов и прочего) обеспечивается в любом случае только ручной проверкой. Автомат помогает исключительно на предмет борьбы со склерозом и невнимательностью. При этом в сколь угодно отдельном поле точно так же можно написать любую чушь, а настроить добавление issue description в commit message при мерже бранчи - абсолютно не проблема, если хочется. Но обычно - нафиг не надо. Ну просто потому что ценность issue основная - пока они в работе, а дальше - почти всё равно, что там, если речь не о коммерческих проектах, где надо отчитываться и обосновывать.
ага, "ваша история никому не нужна".
>> ценность issue основная - пока они в работеЕсли код не приходится поддерживать годами.
Приехали. Появилась работа, которой не ждал. На битбакете лежало 8 проектов древних мелких. Теперь их надо высасывать и конвертировать в git, иначе накроется архив медным тазом :-(
высосать и положить на selfhosted hg - не, никак?
https://www.mercurial-scm.org/wiki/MercurialHostingну или self-hosted, конечно
https://code.rhodecode.com/ поддерживает hg, git и svn welcome
> ... svn welcomeЧто такое "svn welcome"?
Все правильно сделали. И они молодцы - предоставили уйму времени и инструменты для миграции с hg на git. Все четко.
>> По данным опроса Stack Overflow почти 90% разработчиков предпочитают Git, а Mercurial используют всего 3% опрошенныхПравда по данным того же опроса 16% вместо vcs выкладывают архив с кодом в сеть. Разве Atlassian не видит бизнес перспектив в организации удобного файлообменника?
Поначалу все радовались, как интернет-технологии позволяют сервисам обслуживать «длинный хвост» — то есть тех клиентов, которые не входят в основной «топ».И вот маятник качнулся обратно: всё больше и больше проектов обрезают своё мясо, зачастую — саму свою суть (как «Firefox»), чтобы «лучше сконцентрироваться на нуждах 80%».
Удручает то, что репозитории будут удалены
Пару лет назад, когда я переходил на Git, frej/fast-export не умел конвертировать мультирепозитории и сама идея висела на их баг-трекере несколько лет. Поддержка такого сценария была добавлена примерно 8 месяцев назад. Если кто уже переводил мультирепозитории с Mercurial на Git: оно стабильно работает?; на что нужно обратить внимание при переходе? Спасибо.
Зря.
всегда знал, что бб рано или поздно накроется, и не использовал.а всем остальным предлагаю задуматься над отсутствием привязки хранения коментариев в MR и issue к коду во всех любимых гит-сервисах. Мейл-листы не так плохи, ребята.
мейл-листы в данном контексте - тоже не сахар.Issues и подобные надо бы привязывать к самой репе.
Самое смешное, что в Мозилле потом, вцелом, сожалели что выбрали меркуриал. Во всяком случае в багзилле было немало едких комментов про этот "чертов меркуриал и как он достал". А все потому что решения принималось по бизнес интересам, а не техническим.
едких комментов про "чертов гит" ничуть не меньше где угодно :-)
Прекрасно помню этот процесс выбора. Решение принималось после очень долгих и тщательных тестов, именно по техническим результатам и удобству использования. Об этом можно и сейчас, наверное, найти записи в блогах мозиллы того времени. Никаких интересов у бизнеса в какой-либо из этих систем не было.
У меня подгорело. Ну не нужен мне в битбакете гит. Несколько лет пользуюсь битбакетом и меркуриалом. Ну что же, если заставляют гит - уйду на гитлаб/гитхаб, им же хуже, меньше юзеров будет. Как их выкупил Atlassian, так и пошли они под откос.
> уйду на гитлаб/гитхаб"назло маме отморожу уши"
self-hosted вроде совсем не сложно, не?
Это вы фанатам гитхаба говорите.
Гитхаб это прежде всего соцсеть такая, гит там вторичен. Если хочешь контрибьюшенов и при этом твой проект чуточку менее популярен, чем Линукс - приходится. Нынешнее поколение считает, что пуллреквест это кнопочка на гитхабе.Сдохнет и черт с ним, туда ему и дорога, все равно все миррорится на селфхостеде.
> Гитхаб это прежде всего соцсеть такая, гит там вторичен.Этот анон зрит в корень. Собственно, вот и ответ на все вопросы о популярности, конкуренции и так далее. Стадо ломится на то, что сегодня модно.
> Гитхаб это прежде всего соцсеть такая, гит там вторичен.так и ведро - тоже.
Не, ведро в основном для приватных реп. В опенсорсе там движухи практически никакой. Все на гитхабе.
а ты думал, приватным разработчикам не нужна социалочка?(может ты еще и последний заход сцукенберга пропустил? Да-дад, мордокнижка повернулась к "private communications", всей, хгм, мордой. (нет,нет, они не йопнулись - просто это слово означает не то что ты первым подумал))
еще как нужна - в комит-мессадж реплай "КГ/АМ" не напишешь!
Ну может кому-то и нужно. По моей практике, за социалочкой все идут в гитхаб, а на битбакете тихо себе пилят приватные проекты в узком коллективе, который и так прекрасно общается в каком-нибудь Slack-е.
> self-hosted вроде совсем не сложно, не?вообще-то сложно. Тебе последнюю историю с rce в gitea напомнить?
Да-дад, волшебная игогошечка, православные подходы - уп-с, rce - кто бы мог подумать, да и было бы - чем?Ну и вот хочется тебе бегать впереди этого паровоза, двери ему открывать?
Да я этим китайцам никогда не доверял. :-)Если для себя - то, прежде всего, зачем вообще на git переходить? В меркуриале вполне вменяемая стандартная морда. Ну и trac есть, если что.
> В меркуриале вполне вменяемая стандартная морда. Ну и trac есть, если что.в каком, гришь, годе в ем последний раз обновляли меркуриаловский плагин и для какой версии?
При том что и сам-то трак уже скорее мертв чем жив.
Но да, для себя, любимого, трак не особо и нужен, хватит голой vcs. Переписываться самому с собой - первый шаг к деменции.
А вот как только тебя становится хотя бы двое - начинаются пляски хотя бы даже банально с прикручиванием авторизации. В этом плане hg ничуть не лучше гита.
На fossil в таких мелких проектах, кстати, очень рекомендую смотреть.
Я уже не помню, в чем у меня там было дело (сколько лет-то прошло...), но давным-давно выбрал Mercurial, потому что авторизацию в нем было намного проще настроить. :-)
> Но да, для себя, любимого, трак не особо и нужен, хватит голой
> vcs. Переписываться самому с собой - первый шаг к деменции.А больше todo-листы-переростки складывать и некуда. Листки на мониторе удалённо не обновишь.
>> Но да, для себя, любимого, трак не особо и нужен, хватит голой
>> vcs. Переписываться самому с собой - первый шаг к деменции.
> А больше todo-листы-переростки складывать и некуда. Листки на мониторе удалённо не обновишь.я их в devnull все больше - если не нашлось времени сделать здесь и сейчас - значит, уже не в этой жизни. Ну можно еще ветку завести имени этого туда, в тудой и написать - но последнее время и это лень.
А для проектов на два и больше человека - да, приходится пользоваться trac, потому что мэйллисты никто не умеет и гугель их не любит.
> Да-дад, волшебная игогошечка, православные подходыИгогошечка, в первом приближении, вполне нормальная. Синтаксис простой и понятный, без изъ… …гибов. Компилируется в статически слинкованный нативный бинарник. Пока не нашёл, увы, как ею собирать хеллоуворлды под Windows 98.
> Синтаксис простой и понятный, без изъ… …гибов.Какие-то неочевидные особенности := и = в разных скоупах, func (*очень) читаемые(одинаковые) (круглые, скобки) {}, потому что кто-то <> уродством посчитал, кругом война сторонников и противников костыля им. interface {}… Хорошо весь мой код укладывается в один файл, участвовать в холиварах соседей, пишущих тут на этом комбайны, и заниматься IDE assisted copy and paste желания нет никакого.
>> Синтаксис простой и понятный, без изъ… …гибов.
> Какие-то неочевидные особенности := и = в разных скоупах, func (*очень) читаемые(одинаковые)
> (круглые, скобки) {}, потому что кто-то <> уродством посчитал, кругом война
> сторонников и противников костыля им. interface {}… Хорошо весь мой код
> укладывается в один файл, участвовать в холиварах соседей, пишущих тут на
> этом комбайны, и заниматься IDE assisted copy and paste желания нет
> никакого.Издержки обратного наследия, надо полагать. Не думаю, во всяком случае, что Пайк и Керниган^W Томпсон недостаточно компетентны в своём деле. Впрочем, я _их_ книжку про игого ещё не читал. :)
Насколько мне помнится про := и =, правило употребления там простое: в краткой форме записи надо писать как в Паскале, уповая на автоматическое определение типа игогой, а если переменная уже объявлялась, то дальше можно (и нужно!) как в Си.
Мне в игогошечке очень понравилась утилита форматирования говнокода.
И неплохую специальную игогошную IDE обнаружил:
http://liteide.org/en/
https://github.com/visualfc/liteideMade in Japan!
ЗЫНашлось по игогошной теме: https://habr.com/ru/company/mailru/blog/314804/
ЗЫ ЗЫПредполагаю, что авторы при проектирования Go сознательно и намеренно сделали многое, что не нравится людям, привыкшим к другим языкам. Например, жёстко заданный стиль оформления исходного текста. Недостаток или благо? Смотря с какого ракурса посмотреть: меньше свободы самовыражения, но и меньше обезьянинга.
>Made in Japan!Скорее ин чайна. По непонятной причине на го пишет много китайце.