Ещё одна фича Тулбокса — уметь вызывать IDE по ссылке.
Вопрос не в тему статьи, но раз уж речь зашла об этом… А какие ещё операции поддерживаются, кроме вызова диалога клонирования репозитория? Можно ли так дёрнуть какой-нибудь плагин, например? И открыт ли формат URL?
Я когда-то переводил статью коллеги о монолитных репозиториях, в которой освещалась, в частности, проблема производительности. Впрочем, там, скорее, более общие слова, а не детальный анализ, так что еще одна статья на тему будет интересной.
Привыкнуть можно ко всему, безусловно. Но что плохого в том, чтобы добавить опцию, согласованную с опциями других команд? Согласованность интерфейса (неважно, какого именно: API, UI, CLI, ...) — это важная характеристика.
Если же рассматривать замечание автора про скорость набора в отрыве от всего остального, то я согласен, аргумент слабый. Но стоит ли к нему придираться?
Я имел в виду то, что созданные в Facebook расширения опираются на наличие memcache — он уже был у FB для других целей, так что его просто переиспользовали. Поэтому это уже не Mercurial сам по себе.
Есть подозрение, что 8 — это маленькое число, и если Вам удобнее держать их вместе, то надо так и делать, пока что не опасаясь разрастания репозитория, — достаточно помнить о бинарных файлах (в смысле, что добавлять их надо аккуратно или хранить в LFS).
Проблемы, связанные с количеством файлов, коммитов и веток становятся заметными при очень больших абсолютных значениях.
Как упомянуто в статье, Mercurial тоже надо (было) допиливать для действительно большого репозитория. И эта доработка, на самом деле, решает лишь часть проблемы.
Ну, ещё есть время оставлять там +1 :) Этот релиз пока что Bitbucket Server, но уверяю, комментарии с пометкой STAFF в упомянутой теме — не пустые обещания.
По крайней мере, следующим (поверхностное сравнение в несколько запросов):
насколько я могу судить, codefinder не поддерживает ни кириллицу, ни всякие умляуты;
как-то он и на простой запрос `hello test` странно реагирует — видимо, он поддерживает только точное вхождение подстроки;
вдогонку к предыдущему: поиск в Bitbucket учитывает camel, snake и kebab-case в словах (например, запрос `riot` найдет и `RiotPolice`), а кроме того, имеет некоторую эвристику для сортировки результатов;
встроенный поиск знает о контексте: если начинать поиск, находясь в проекте или репозитории, модификаторы будут подставлены в запрос автоматически;
наконец, Bitbucket Server может быть полностью закрытым от внешнего мира, и тогда любой сторонний поисковик не имеет смысла. И даже если он закрыт не полностью, сторонний сервис не сможет индексировать приватные репозитории, а встроенный поиск это делает, но при этом, разумеется, учитывает права доступа для пользователя, выполняющего поисковый запрос.
Колонка рецензентов со статусами уже реализована в новой странице пулл реквестов — как раз та самая бета, которая в последнем разделе статьи упомянута. Можете её включить и уже пользоваться. Рано или поздно новый дизайн запустят для всех.
Что касается добавления ещё одной колонки в таблицу пулл реквестов, мне надо уточнить, как именно (и можно ли) это сделать.
В общих чертах, подобное расширение должно быть отдельным сервисом, к которому Bitbucket будет обращаться за данными с помощью REST-запросов, и который, в свою очередь, сможет вытягивать необходимые ему данные из Bitbucket и JIRA также с помощью REST. Соответственно, в Bitbucket этот сервис зарегистрирован как Connect-расширение, а в JIRA аутентифицируется через OAuth.
С другой стороны, вам может оказаться достаточным настроить связь между Bitbucket и JIRA, которая превратит все упоминания ключей задач в пулл реквестах и комментариях коммитов ссылками в JIRA.
Это меняет дело. От иконок репозиториев, действительно, решили отказаться, когда появились проекты. Подробности есть в обсуждении на Reddit (Dan Bennett из команды Bitbucket Cloud).
Идея в том, что проект стал промежуточным слоем между командой и репозиторием и добавил свою иконку к тем двум, но такое изобилие иконок сделало бы интерфейс перегруженным, поэтому от чего-то надо было избавиться. А с учётом того, что иконками репозиториев пользовалось около 6% людей, выбор пал на них.
К сожалению, от таких решений всегда кто-то страдает :(
Не уверен, что правильно понял, о каком списке вы говорите. Насколько я вижу, у проектов по-прежнему есть свои иконки.
Предположу, что вы смотрите на первую страницу профиля команды (хотя там у проектов совсем нет иконок), — как отображаются проекты на вкладке Projects?
Пока что нет, к сожалению. Кое-какие подробности можно найти в этой задаче.
Не могу с вами согласиться, вот мои 5 копеек:
На одной странице оказались бы: статистика репозитория, строка со ссылкой для клонирования, селектор ветки, дерево файлов, превью README и лента событий, — на мой взгляд, вышла бы плотная информационная каша, а каждому элементу в ней пришлось бы ужиматься, что ещё больше усложнило бы их восприятие.
Если в корне хотя бы полтора десятка файлов, текст README может оказаться за краем экрана. Польза от такой посадочной страницы будет значительно меньше.
Страницу Overview можно расширять с помощью Bitbucket Connect.
С другой стороны, если я вас не убедил, и у вас есть хорошая идея, как можно было бы сделать лучше, опишите её в задачке.
В Вашем примере первая строка игнорирует не саму папку uploads, а все файлы/папки в ней.
В 2.7 поддержали отмену игнорирования файла даже если какая-то из родительских папок игнорирована. То есть, исключить файл uploads/some_dir/file из приведённого ограничения Git 2.7 сможет, а 2.6 — нет.
Вопрос не в тему статьи, но раз уж речь зашла об этом… А какие ещё операции поддерживаются, кроме вызова диалога клонирования репозитория? Можно ли так дёрнуть какой-нибудь плагин, например? И открыт ли формат URL?
Спасибо.
Если хочется с UI, то у Media Human есть неплохой клиент.
Опция игнорирования whitespace'ов теперь доступна всем. Она прячется в менюшке за тремя точками.
Хорошие новости: аватарки репозиториев вернулись :)
Пока что они выключены по умолчанию, но Вы можете включить их в настройках команды, фича называется «Bring back repository avatars».
Если же рассматривать замечание автора про скорость набора в отрыве от всего остального, то я согласен, аргумент слабый. Но стоит ли к нему придираться?
Проблемы, связанные с количеством файлов, коммитов и веток становятся заметными при очень больших абсолютных значениях.
По крайней мере, следующим (поверхностное сравнение в несколько запросов):
Что касается добавления ещё одной колонки в таблицу пулл реквестов, мне надо уточнить, как именно (и можно ли) это сделать.
В общих чертах, подобное расширение должно быть отдельным сервисом, к которому Bitbucket будет обращаться за данными с помощью REST-запросов, и который, в свою очередь, сможет вытягивать необходимые ему данные из Bitbucket и JIRA также с помощью REST. Соответственно, в Bitbucket этот сервис зарегистрирован как Connect-расширение, а в JIRA аутентифицируется через OAuth.
С другой стороны, вам может оказаться достаточным настроить связь между Bitbucket и JIRA, которая превратит все упоминания ключей задач в пулл реквестах и комментариях коммитов ссылками в JIRA.
Идея в том, что проект стал промежуточным слоем между командой и репозиторием и добавил свою иконку к тем двум, но такое изобилие иконок сделало бы интерфейс перегруженным, поэтому от чего-то надо было избавиться. А с учётом того, что иконками репозиториев пользовалось около 6% людей, выбор пал на них.
К сожалению, от таких решений всегда кто-то страдает :(
Предположу, что вы смотрите на первую страницу профиля команды (хотя там у проектов совсем нет иконок), — как отображаются проекты на вкладке Projects?
С другой стороны, если я вас не убедил, и у вас есть хорошая идея, как можно было бы сделать лучше, опишите её в задачке.
В 2.7 поддержали отмену игнорирования файла даже если какая-то из родительских папок игнорирована. То есть, исключить файл uploads/some_dir/file из приведённого ограничения Git 2.7 сможет, а 2.6 — нет.