- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
switch ( ! empty($rules['last_online']) )
{
case '3days':
$where .= " AND last_online > NOW() - INTERVAL '3 DAYS' ";
break;
case 'week':
$where .= " AND last_online > NOW() - INTERVAL '7 DAYS' ";
break;
case 'month':
$where .= " AND last_online > NOW() - INTERVAL '1 MONTH' ";
break;
}
Follow us!
Вместо баг-трекера у разработчиков есть mailing-list: http://news.gmane.org/gmane.comp.version-control.git/ - я тоже предпочитаю баг-трекеры, но в git слишком мало багов, чтобы об этом беспокоиться.
Да, и я кажется выше написал, что знаком с рассылкой, и с тем, как баги исправляются и как быстро. Спасибо, что вы мне об этом напомнили...
Багов - море, особенно изза того, что в коде велосипедов... ну, там все самодельное вобщем. Я вообще не понимаю откуда столько слепой веры у людей. Но, баги в Гите - не главное, там уебищная сама задумка. Я даже не знаю... я до сих пор думаю, что это просто сильно затянувшийся розыгрыш.
Это абсолютно не важно на каком сервере репозитории. Гит просто даже никогда не пытается прочитать логин/пароль второй раз, не важно куда коммитить. Это как раз таки можно настроить на уровне .netrc например, или там, например, в раутер зашить :) чтобы наверняка, но Гит сам по себе тупо игнорирует такие настройки.
Забыл дописать, что git push (при использовании ssh протокола) тупо вызывает ssh (или то, что прописано в переменной окружения GIT_SSH) с параметрами:Поэтому ни о какой аутентификации со стороны гита, а следовательно и о чтении всяких там конфигов, посвященных аутентификации не может быть и речи.
P.P.S. Может быть у вас какой-нибудь гитовый гуй такой фигней с кешированием паролей страдает?
P.S. А есть ли смысл юзать запароленную HTTP/HTTPS репу? Имхо корячить WebDAV ради пуша в нее это намноого большее извращение чем gitolite/gitosis.
Зачем нужно задавать пароли в файлах настроек Гита: предположим, у вас на одном сервере есть репозитории с разными логинами/паролями, тогда настройки SSH не достаточно специфические.
Эм. Не знал о такой возможности. Можно ссылку на ман, где описывается подобная настройка?
Вот тут описан механизм, только вместо user@repository используйте user:password@repository схему.
> и есть репозиторий, в котором, ну я не знаю... я разрабатываю порносайт?
Мы начали с того, что у вас уже два репозитория, и есть желание, чтобы один из них никто не ассоциировал с вами и, желательно, не видел. При чём здесь сомнительные проблемы с разными паролями для одного пользователя на одном и том же хосте?
Ну для создания вашей схемы, в том же гитолайте можно сгенерить по ключу на каждую репу, и выставить этому ключу право на доступ только к своей репе.
Кстати, в том же гитолайте можно мудаку-фрилансеру поставить R доступ на master и W доступ на их личную ветку. А мерджить самому, заодно просматривая чего они там наворотили. И овцы сыты, и волки целы.
О боже... git describe же. Показывает для коммита версию в виде 1.0-37-g86c283a, где 1.0 - последний тег, навешанный перед текущим коммитом, 37 - количество нетегированных коммитов после того самого тега. 86c283a - кусок айдишки коммита. Чем не хронология?
После ваших примеров мне вспоминается это: "Я стою на асфальте, в лыжи обутый..."
На практике, не зависимо от размера организации и внутреннего устройства, я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой. Любая организация, по своей сути является строгой иерархией, не допускающей разногласий в смысле порядка принятия решений, и в том числе связанных с тем, какой код она производит. Я работал в проектах типа САС, использующихся в Бритиш Эирлайнз и в стартапах из 2-3 человек. Нигде и никогда распределенная система версий ничего не улучшила. Иногда запутывала. Т.е. ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы. Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять и они занимают вцелом гораздо меньше места (Гит хранит всю историю проекта в каждой копии, в то время как централизованные системы хранят историю в одном центральном месте).
Чтобы лучше обьяснить это, приведу пример из САС-подобного проекта, где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер. С точки зрения админа Гит дублировал бы информацию на одном и том же физическом сервере. Т.е. заявленная "надежность" на практике была бы фикцией, только увеличивавшей нагрузку на сеть и требования к обьему носителей информации.
Что это значит?
>Нужны именно версии, в хронологическом порядке
git log выводит в хронологическом в пределах ветки.
>я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой
Если вы работали с git, то сталкивались с DVCS - у каждого пользователя своя, независимая копия репозитория. Преимущество - отсутствие необходимости в сервере для того, чтобы работать с репозиторием, со всеми вытекающими плюсами. Мой коллега мне рассказывал о трудностях, которые у него возникали с svn, когда он работал удаленно - в тот раз пришлось поднимать наружный сервер.
>Любая организация, по своей сути является строгой иерархией
1. Не любая. Скорее наоборот: строгая иерархия является исключением. Христоматийные примеры организаций без иерархии: valve, 37signals. Бытовые примеры: любая маленькая компания, в которой иерархия весьма условна.
2. Даже если так, это не является аргументом против DVCS
>Нигде и никогда распределенная система версий ничего не улучшила.
А у меня улучшила. Deal with it.
>Иногда запутывала.
Цитата про лыжи выше.
>ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы.
Использовала. У каждого пользователя был свой репозиторий. См. выше.
>Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять
Не относящийся к вопросу аргумент. Дело админа - установить и настроить.
>и они занимают вцелом гораздо меньше места
Приведите цифры. По моим данным git гораздо компактнее хранит файлы репозитория.
>Гит хранит всю историю проекта в каждой копии
И это удобно и быстро.
>где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер
Это действительно хороший пример, где централизованные VCS имеют преимущество. К сожалению, для большинства компаний это слишком дорогое решение.
Но про занимаемое место все-таки отвечу, т.как тут fail at reading comprehension. Гит хранит историю вместе с каждым репозиторием в то время как централизованые системы хранят историю только в одном месте. Как бы там Гит экономно ее не хранил, то при наличии более одного репозитория проиграет. А для компании с тысячами программистов это выливается в серьезные суммы. Когда я говорил с девушкой администрирующей билды / репозитори в Хьюлете, то она сказала, что по их подсчетам, им бы только на наш отдел пришлось бы купить еще две машины (т.как сотрудники получали каждый по ВМ для работы, и обьемы кода были такие, что пишлось бы по-другому разбивать дисковое пространство на уже имеющихся машинах, для того, чтобы Гит туда влез). Только над нашим проектом работало больше сотни человек (в нашем отделе - примерно десять). Итог - дешевле было бы купить хорошую систему версий, чем платить за железо для говенной, но бесплатной.
Вот цены на тот же perforce: http://www.perforce.com/purchase/pricing-licensing
При покупке за $480 на 100 человек имеем одноразовую трату в $48000. Самые дорогие HDD, которые я нашел, обойдутся в 20000 руб/Тб. На $48000 можно купить ~72Тб. В этот объем можно вместить 300-400 ТЫСЯЧ копий довольно больших git-проектов, то есть для исходных 100 человек имеем 3-4 тысячи репозиториев на брата.
Я не говорю, что из-за этого не стоит выбирать perforce, ведь у него наверняка есть множество преимуществ. Я также не утверждаю, что git - это лучший вариант. Я просто с ним лучше всего знаком.
Сорцы смотрел как-то ради интереса, никакого криминала не увидел. Обычный промышленный сишный код. Великов много, но это же pure Сишка, там такая библиотека, что свой велопарк приходится писать в любом проекте.
Багов за три года работы с git не наблюдал.
Получается что не совсем. Для ssh, да, делегирует. А вот для HTTP/HTTPS он юзает cURL, и с паролями обращается самостоятельно (см. git-credential-cache).
> Багов за три года работы с git не наблюдал.
Плюсую.
P.S. Я видимо багов не наблюдал, т.к. за все время работы с гитом ни разу не пользовался http/https транспортом. Только ssh через гитолайт или ssh на гитхаб\битбакет.
То, что он "Юниксовая" программа, не помешало им так же встроить вовнутрь свой grep с блекджеком и шлюхами и еще много чего такого.
Ну вот мне выдали в вотчину какой-то покрывшийся плесенью Центос, на котором нужно соорудить багтрекер + вики + репу + тестовый сервер + СиАй сервер и т.п. Сабвершн поставился без инцидентов за меньше чем 5 минут. Немножко повозился прикручивая его г Багзилле, но срослось в итоге. Гит - это такая феерическая муть по сравнению... Тоесть, вы не подумайте, я не сравниваю работу (хотя и там у меня есть нарекания), я просто говорю об интерфейсе программа-человек. В Гите политика не задумываться об удобстве разработчика, а следовать каким-то надуманным принципам. Настроить авторизацию (серверную часть) - это ад, бессмысленный и беспощадный. При чем, мне было бы не жалко, если бы это несло в себе какие-то бонусы. Так ведь нет. Те "улучшения", изза которых система становится более сложной - как раз та часть системы, которую нужно сразу же удалить и никогда не использовать.
Так, например, авторизация по буличным ключам компьютера недопустима в мало-мальски большой организации, особенно, если она позволяет пользователям доступ с домашних компьютеров.
> В Гите политика не задумываться об удобстве разработчика
В гите политика думать, что ты делаешь, и знать, как он работает. Гибкость просто неимоверна, позволяется даже переписывать историю (rebase, squash), чего вроде бы не позволяет ни одна другая система управления ревизиями. Если использовать централизованную топологию, отличия от subversion минимальны.
Гит хранит не последовательность патчей, он хранит полную историю коммитов, знает, что, когда, как мёржилось. Это превращает мёржи в довольно тривиальную задачу (если работа была правильно распределена и конфликтов не много). Я, к примеру, трижды подумаю прежде, чем использовать ветку в subversion. В гите я даже думать не буду. А ведь у меня довольно богатый опыт мёржа веток в svn.
> если она позволяет пользователям доступ с домашних компьютеров
В чём проблема с доступом с домашних компьютеров по ключу?
Основная проблема с гитом - относительная сложность организации аутентификации, т.е. разделение прав. Эту проблему решают отдельные приложения вроде gitlab и gerrit.
В том же самом, в чем и проблема с доступом с домашних компьютеров по паролю - в доступе с домашних компьютеров ;)
Гит не хранит никакой истории, которую можно было бы осмысленно использовать. Он хранит массу информации, большая часть которой не представляет из себя никакой практической ценности. Это следствие его дибильного подхода к решению конфликтов, которые по-сути приходится решать в обход системы контроля версий.
Проблема в том, что домашний компьютер не находится под защитой корпоративного фаирвола и т.п. Если компутер сам, без содействия пользователя (т.е. помня пароль) может залогиниться в корпоративную сеть - это беда. Если такому пользователю сделать веб-авторизацию, то у него по крайней мере будет выбор: запомнить пароль / использовать менеджер парлолей, или тупо записать где-нибудь. В случае с авотизацией по публичным ключам - в мире может быть есть человек десять, способных запомнить свой публичный ключ. Остальные его будут просто записывать где-нибудь. Фрилансеры почти наверняка будут логинится из Виндовса - где никаких ограничений на доступ к их кючу не предвидится.
А если пользователю сделать ключ - то у него тоже будет выбор - сгенерить ключ без пароля, либо сгенерить ключ с паролем, и записать этот пароль, либо сохранить в менеджере паролей (аля ssh-agent).
Проблема то совсем не в ключах и паролях. Вы серьезно считаете, что трояну, сидящему на компе того самого фрилансера, ключ угнать легче чем спиздить пароль вводимый юзером с бумажки? Да это абсолютно равнозначные по сложности действия.
История в git ничем не хуже, чем в subversion, даже лучше, ибо хранит больше информации. Например, путём слияния каких коммитов был получен мёрж. Конфликты решаются практически также, как и в svn, впрочем, практически в любом VCS мёрж конфликтов есть тёмная магия и у неопытных пользователей вызывает ступор.
> в мире может быть есть человек десять, способных запомнить свой публичный ключ
Нафига запоминать публичный ключ? Он на то и публичный, чтобы его все знали. Он не предоставляет никакой ценности. По-настоящему важен закрытый ключ, и он обычно генерится с правами доступа 600, чтобы кроме создателя его никто открыть не мог. И обычно его стараются либо переносить на защищённом носителе информации, либо генерить для каждого компьютера заново.
С гитом же ситуация намного лучше - можно коммититься сколько душе угодно, можно откатывать изменения, если что-то не то натворил. И, закончив логически осмысленный кусок (пофиксив баг, запилив небольшую фичу), можно смерджить свои изменения с матстером и запушить их.
С Сабвершном - это вполне известная неприятность - очень затрудниетельно в любом виде отойти от основной рабочей версии. Как правило это нужно / приходится делать с разрешения / в присутствии админа. Но это правильно! Т.как программист не должен плодить версии безконтрольно, потому что этим он создает проблемы административного порядка, которые решать уже не ему. У Сабвершна нет такого понятия как "локальная история", поэтому тут и сравнивать бессмысленно, но если сравнивать с Перфорсом, то там это удобнее, чем в Гите, и ничего вообще не переписывается, т.как этот процесс не связан напрямую с историей всего репозитория.
> Вы серьезно считаете, что трояну [...]
Тут даже не про трояны речь. Если авторизируется компьютер, то любой, кто воспользуется этим компьютером без вообще каких либо усилий сможет авторизироваться. Это как разница между открытой дверью и дверью закрытой на амбарный замок. Амбарный замок просто сломать, имея инструменты, но все таки мы считаем такую дверь более защищенной.
Но в любом случае, даже если кто-то злой имеет доступ к компу горе-фрилансера, то что он сделает получив доступ только к гитовой репе (которую вы, как вы написали выше, выделили специально для этого фрилансера)? Все, что он сможет сделать - закоммитить туда какую-нибудь злую херню... Но вот с тем же успехом он может внести эту херню ему в локальную копию, не имея никаких ключей и паролей, а тот не заметив подвоха закоммитит ее сам...
P.S. С перфорсом вживую не встречался, но посмотреть давно хочу. Надо будет попробовать поюзать его на каком-нибудь небольшом но реальном проекте.
Не знаю, нужно ли оно, когда вокруг столько бесплатных простых инструментов с отличной документацией.
Вобщем, типичное необдуманное позерство и groupthink, которого везде и всегда полно.
Это уже слишком толсто. А с виду ты худенький
Перефразирую Классика
"There are only two kinds of technologies: the ones wvxvw complains about and the ones nobody uses."
С опцией M ваша история станет линейной и шелковистой.
Если ваш перфорс такой удобный и хороший почему вы не убедили своих программистов его юзать?
P.S. Если в гитолайте включены RW+M у админа и RW у программистов, то история линейная, менять ее без помощи админа нельзя, что же вам еще нужно ;)
Я один, а их много... люди, как правило не пытаются самостоятельно анализировать: что всплыло в Гугле с большим счетчиком - то и используют. Ни в одном месте, где я работал, за исключением того, где использовался Перфорс, люди либо ничего кроме Сабвершн никогда не видели, либо это был выбор между Сабвершн и Гит. Но дело даже не в этом. Перфорс - коммерческий. И если уже быть до конца откровенным, то тут у некоторых иногда даже Виндовса лицензионного нет, а о том, чтобы взять коммерческий продукт вместо популярного бесплатного, каким бы хорошим он ни был... честно, я бы тоже взял что-то бесплатное. :( Но я бы смотрел в сторону Базара, т.как написано на Питоне и его просто интегрировать с билд скриптами (если они тоже на Питоне), и с Си-Ай скриптами, если они тоже на Питоне, и с еще кучей всего, что тоже может случайно быть написано на Питоне...
Ок. Пишем в конфиге гитолайта обычным программистам RW, админу RW+. Выдыхаем.
Далее. Из речей @wvxvw складывается ощущение, что админы - существа гораздо более глубокомысленные и знающие, чем программисты. По моему опыту они обычно ленивее и лучше противостоят нововведениям, ведь если что сломается, иметь будут их, и я ничего не имею против. Ещё они иногда лучше разбираются в железках и знают, что где лежит, и как оно включается. Но менять историю в репозитории я бы своим админам не доверил.
Так что единственный мотив давать права на изменение истории админам - тот факт, что она им абсолютно неинтересна, и они в неё никогда не полезут.
Я так понял, что админ править историю будет только тогда, когда к нему прибегут программисты, и объяснят начерта им надо ее менять. Я думаю в остальное время ему будет просто лень копаться в проекте, у админов и без этого другой работы полно. А права админу, управляющему репой не помешают, т.к. иначе ему придется их выдать самому себе, когда возникнет критическая ситуация.
wvxvw против gita.
От создателей В js скушное ооп и Некошерный эрланг.
Смотрите этой зимой на говнокоде.
Лично мне эта часть показалась скушной и избитой. Актерская игра никакая. Сплошная толстота.
fix
Соглашусь, срач вышел унылый. И возник на пустом месте.
Возвращаясь к основному обсуждению. Само собой, опять даты, опять PHPSQL, но я почему-то пошёл против общественного мнения. Как много иррационального в наших поступках. Хотелось бы услышать мнение ещё троих.