mxgoncharov4 апр 2016 в 20:39

Новый дом для репозитория или история переезда на GitLab

4 мин

34K

Git * Ruby on Rails * Системы управления версиями *

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

FRWHate 4 апр 2016 в 20:54

Попробуй Gogs. Написан на Go и ввиду этого быстрее и жрёт оперативы поменьше
gogs.io

mxgoncharov 4 апр 2016 в 20:54

Оу. Люблю Go. Посмотрю. Спасибо)

SL_RU 4 апр 2016 в 21:32

Нам тоже gogs больше понравился.
После нескольких месяцев использования gitlab'a попробовали его, да и переехали. Он простой, быстрый и нет всяких ненужных нам лишностей. И ещё опенсорсный.

mxgoncharov 4 апр 2016 в 21:33

На GitLab мы не так давно переехали, и пока очередной переезд точно не грозит. Но для себя я точно Gogs изучу.
А если не секрет, что именно сподвигло уйти с gitlab'a?

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

creker 5 апр 2016 в 09:00

Вы из сорсов что ли ставили? Куда проще из пакетов ставить. Тогда gitlab устанавливается и обновляется в один клик. Проще некуда его администрировать.

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

creker 5 апр 2016 в 10:01

Gitlab сами быстро патчат уязвимости, так что недостаток этот отпадает. А все остальное не причиняет мне неудобств. Оно просто работает и работает хорошо, им удобно пользоваться, дофига функционала. Собственно, ничего лучше Gitlab на рынке и нет. Только платные решения.

pav5000 5 апр 2016 в 12:31

Можно еще проще, запустив официальный докер-контейнер.

Sys_Admin 5 апр 2016 в 18:34

github.com/sameersbn/docker-gitlab гораздо функциональнее.

Botkin 6 апр 2016 в 07:25

GitLab сейчас ставится и обновляется при помощи apt-get install gitlab-ce

zelenin 4 апр 2016 в 22:58

я безуспешно пытался несколько раз завести на своем digitalocean docker с гитлабом, но ему не хватает самого дешевенького тарифа, т.к. прожорлив он весьма.
Около пары месяцев назад открыл для себя gogs — это чудо. Весь базовый функционал есть, а памяти жрет в десятки раз меньше. Только что поднятый инстанс, если не ошибаюсь, занимал всего 8 мб памяти (гитлабу не хватало 512-ти).
В общем присоединяюсь и советую.

pav5000 5 апр 2016 в 12:33

Выглядит вкусно, а какой-нибудь CI имеется, чтобы тоже на Go и легко интегрировался с gogs?

ashumkin 4 апр 2016 в 21:00

две беды у GitLab'а есть. как только встречаются:

не-UTF8 кодировка имён файлов
не-UTF8 кодировка содержимого файлов
то тут-то он и не справляется

и если первое можно победить одномоментной миграцией, переименовав файлы
то со второй у него долгая и, судя по всему, так и не исправленная, история…
а патчить каждую версию (или, тем более, просить админов) — увольте

mxgoncharov 4 апр 2016 в 21:32

Честно говоря, не сталкивался с этой проблемой. Надо будет подробнее изучить. Но я сомневаюсь, что этот вопрос никогда не поднимался. Если что найду — отпишу)

ashumkin 4 апр 2016 в 21:35

да в том-то и дело, что поднимался, и не раз )) только предлагавшейся настройки "кодировка файлов" так и нет )
З.Ы. GitLab юзает gem charlock-holmes, который автоопределяет кодировку, но на малом объёме входного текста — неверно

btd 5 апр 2016 в 05:42

chalock-holmes использует libmagic, ее же использовал ранее гитхаб, он тоже на ваших данных не работает?

ashumkin 5 апр 2016 в 06:00

Без понятия. У меня уже нет времени (да и желания особо) ещё раз разворачивать GL, чтобы это проверить.
Есть простой синтетический тест проверить libmagic?

btd 5 апр 2016 в 06:11

Скорее всего команда file может выдавать кодировку (вообще там довольно ограниченный набор). По хорошему вместо libmagic они должны были использовать icu chardet или mozillaовский uchardet.
Еще неплохой идей было бы поддерживать файлик на подобии .gitignore или ini где указывались бы глобы и соответствующие кодировки.

ashumkin 5 апр 2016 в 10:41

Еще неплохой идей было бы поддерживать файлик на подобии .gitignore или ini где указывались бы глобы и соответствующие кодировки.

уже всё есть
.gitattributes encoding
только что до этого GitLab'у? )

btd 5 апр 2016 в 10:49

.gitattributes это тема, не знал про этот файлик. Спасибо огромное!
Интересно, хоть какой нибудь хостинг реп его использует?

ashumkin 14 фев 2017 в 08:23

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

oYASo 4 апр 2016 в 21:34

Что за проблемы?
В свое время пару лет сидели на чисто Open Source версиях (когда Enterprise еще не было) — никаких проблем, полет отличный.
Уже давно ушли на стек продуктов Atlassian, но, чисто субъективно, GitLab бегал намного шустрее и жрал на серваке куда меньше ресурсов.

mxgoncharov 4 апр 2016 в 21:37

Я использовал для pet'ов Bitbucket, но по ощущениям как-то GitLab приятнее. Хотя я не нашел супер-отличий. Может дело в том, что Atlassian это все таки по большей части enterprise сегмент, и в нем мало духа авантюризма)

oYASo 4 апр 2016 в 23:49

Ну когда есть все эти Jira, Bamboo, Confluence, Crucible и прочее, проще и быстрее развернуть BitBucket и в пару кликов их подружить.
Да простят меня адепты Java, но у меня аллергия на продукты, написанные этим языком. Если Java, то это сразу надо выделять тонны оперативки и несколько процов, сразу чувствуется какая-то неповоротливость и задумчивость. Но увы и ах, весь интерпрайз на нем, приходится страдать со всеми.

grossws 5 апр 2016 в 07:05

Скажите спасибо поголовью индусов, которые пишут это так дешево. Со всеми вытекающими требованиями к памяти и cpu. Хотя на руби тоже относительно прожорливые поделия получаются.
Тот же youtrack работает шустро и довольно удобен. Хотя тоже на яве (возможно, частично, и на котлине, не знаю).

oYASo 5 апр 2016 в 13:51

Дык я же не спорю. Мало того, тенденция продолжается, так что дальше только хуже будет (или лучше, тут смотря с какой стороны смотреть).

Jira/BitBucket тоже относительно шустро работает, если ресурсов выделить. Но тот же GitLab с той же командой наших разработчиков комфортно работал (да и работает, на самом деле — мы просто его не поддерживаем) при десятикратно меньшей выделенной оперативы. У нас внутренних железок хватает с избытком, так что никаких проблем нет, но вот для других команд тут может быть проблема.

ashumkin 4 апр 2016 в 23:46

проблема отображения diff'ов файлов в кодировке, отличной от UTF-8 (привет из Windows),
также их имён (привет из Cygwin), ну и текстов сообщений коммитов

oYASo 4 апр 2016 в 23:51

Хоть один аргумент в пользу неиспользования UTF-8?
Сами вот уже три в пользу назвали.

ashumkin 5 апр 2016 в 05:56

Есть один… мощный: legacy

oYASo 5 апр 2016 в 13:56

Сорцы-то зачем в непонятных кодировках держать?

Я тоже работал со всякими лохматыми МСВС, где koi8-r (на Linux, черт возьми!) поставлена по умолчанию. Ну это не повод самому говнокодить и держать все в непонятно чем.

ashumkin 5 апр 2016 в 14:09

а кто говорит про «самому»?
я же сказал: legacy! на 200000 строк кода основного проекта (без учёта библиотек)
IDE 10-тилетней давности, без поддержки Юникода
миграция на «современную IDE» = время = деньги, их ни у кого на это нет

xRay 6 апр 2016 в 05:39

Тоже примерно таким https://github.com/xRayDev/gitlab_windows1251/commit/ac65ae9bbafe528566324e6065bf867658ec4dec костылем пользуетесь?

ashumkin 6 апр 2016 в 07:39

да-да, только
мы так и не пользуемся, ибо на тот момент, когда я тестил GL, были ещё баги
PR мой отвергли ))
а поддерживать патчи после обновлений мне не улыбалось )
так что пока gitolite…
но лёгкого управления доступом к проектах, уведомления, построчных комментов к коммитам хотелось бы ))

xRay 6 апр 2016 в 07:48

Надо посмотреть упомянутый в комментариях Gogs. Может у него с этим проблем нет.

ashumkin 6 апр 2016 в 07:53

надо )) но сомневаюсь ))
сейчас «все» почему-то думают, что UTF-8 единственная возможная кодировка ))

ashumkin 6 апр 2016 в 07:52

JFI )
github.com/ashumkin/grit_ext/commit/77f04806d4f2ff1ab9b38512552fa296197c2c3a
github.com/ashumkin/grit_ext/commit/032ca7cf8ec216d07c6e5b89c25f47a26a8be687

xRay 6 апр 2016 в 08:40

Хе всего одна строчка :)
Еще пачте правится второй файлик и там точно такой же баг в геме gitlab_git от разработчиков GitLab.

ashumkin 6 апр 2016 в 08:47

кругом костыли ))
я тут надысь на похожую тему FlexGet фиксил ))
там, правда, ситуация в обратную сторону ))) текст приходит в UTF-8, а его перекодируют в latin1 зачем-то

xRay 5 апр 2016 в 13:09

Да. Так есть. Накладываю патч (в пару строк на два файла) на каждую. Версию GitLab.
И у GitHub та же самая проблема имеется.

ashumkin 14 фев 2017 в 08:25

поздравляю! наконец-то, услышали
)))

xRay 14 фев 2017 в 17:06

Да я видел. )) И не поверил своим глазам что этот баг таки добавили в беклог.
А в настройках у gogs это сразу учтено.

StamPit 4 апр 2016 в 22:23

А ведь изначально же gitlab, если мне не изменяет память, был как раз веб-интерфейсом для gitolite, так что переезд для нас (5Gb репозиторий, большая часть — PHP) был безболезненным.
Но самый большой плюс GL — это потрясающая документация, спасибо dzaporozhets и команде GL за это.

mxgoncharov 5 апр 2016 в 04:34

Да. Вы правы. Я тоже помню когда GL был еще на gitolite. Но как по мне, если реально нужен подобный инструмент, то gitolite — пережиток прошлого, ИМХО.

mjr27 4 апр 2016 в 22:39

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

StamPit 4 апр 2016 в 23:21

В зависимости от того, что Вам надо. Jira и Redmine (используем второй)

Botkin 6 апр 2016 в 07:27

Мы YouTrack вполне успешно юзаем
confluence.jetbrains.com/display/YTD65/Integration+with+GitLab

norlin 5 апр 2016 в 06:38

Каким инструментом контроля версий пользуетесь вы?

На нынешнем месте работы – CVS.
:trollface:

vayho 5 апр 2016 в 07:46

-не туда-

vayho 5 апр 2016 в 07:54

Еще есть https://github.com/gitbucket/gitbucket для JVM.

Godless 5 апр 2016 в 08:04

а вы пробовали/смотрели scmmanager? Развернули его на работе и дома для домашних проектов — очень нравится. У нас правда, команда не большая, но проектов около 20. Единственное но — оно на java. Пока нареканий не было...

SabMakc 5 апр 2016 в 08:49

Стоит добавить, что SCM-Manager работает не только с Git, но и с Mercurial / SVN.

Amomum 5 апр 2016 в 09:14

Мы используем gitblit. Выбрали его в основном из-за возможности создавать сложную иерархию проектов на сервере. Основные недостатки (для нас), то что по этой иерархии не очень удобно ходить и создавать новые репы. Она в общем списке всегда полностью развернута :)
Но в целом норм.

dmitry_no 5 апр 2016 в 11:34

Есть ещё rhodecode.com. Управляет правами доступа на уровне пользователей, групп или отдельных репозиториев (Git, Subversion и Mercurial). Бонусом — code review функционал и интеграция с issue trackers/CI. Бесплатный до 25 пользователей.

SabMakc 5 апр 2016 в 11:57

Не забываем про его open source форк Kallithea.

dmitry_no 13 июн 2016 в 10:38

RhodeCode тоже open source (AGPLv3 с мая 2016): https://rhodecode.com/blog/113/rhodecode-goes-open-source

10E137 5 апр 2016 в 12:31

Вся прелестность GitLab заканчивается тогда, когда с ним надо работать в корпоративной среде, с необходимостью интеграции issue tracker и все это сдобрено толикой SSO. В моем случае в качестве issue tracker`а была JIRA. Даже Enterprise предлагает только «создание специального пользователя» в JIRA с доступом к JIRA Core. И коменты оно пишет из разряда «mentioned» а не то, что было в коммите.

Kudja 6 апр 2016 в 09:46

Ну тогда в вашем случае полагаю Jira Server использовался, а тогда https://marketplace.atlassian.com/plugins/com.xiplink.jira.git.jira_git_plugin/server/overview чем плох?

dmitry_no 13 июн 2016 в 10:30

RhodeCode (https://rhodecode.com) специально для enterprise сделан. Есть аутентификация через Active Directory/LDAP/Atlassian, интегрируется с JIRA/Redmine.

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