- 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;
}
Int 01.02.2013 18:54 # 0
guest 01.02.2013 22:07 # −1
scriptin 02.02.2013 00:06 # +5
bormand 02.02.2013 00:11 # +2
scriptin 02.02.2013 00:23 # +2
wvxvw 02.02.2013 01:21 # 0
wvxvw 02.02.2013 01:26 # 0
scriptin 02.02.2013 01:58 # 0
Вместо баг-трекера у разработчиков есть mailing-list: http://news.gmane.org/gmane.comp.version-control.git/ - я тоже предпочитаю баг-трекеры, но в git слишком мало багов, чтобы об этом беспокоиться.
wvxvw 02.02.2013 02:55 # 0
Да, и я кажется выше написал, что знаком с рассылкой, и с тем, как баги исправляются и как быстро. Спасибо, что вы мне об этом напомнили...
Багов - море, особенно изза того, что в коде велосипедов... ну, там все самодельное вобщем. Я вообще не понимаю откуда столько слепой веры у людей. Но, баги в Гите - не главное, там уебищная сама задумка. Я даже не знаю... я до сих пор думаю, что это просто сильно затянувшийся розыгрыш.
Это абсолютно не важно на каком сервере репозитории. Гит просто даже никогда не пытается прочитать логин/пароль второй раз, не важно куда коммитить. Это как раз таки можно настроить на уровне .netrc например, или там, например, в раутер зашить :) чтобы наверняка, но Гит сам по себе тупо игнорирует такие настройки.
bormand 02.02.2013 07:32 # 0
bormand 02.02.2013 08:04 # 0
bormand 02.02.2013 08:51 # 0
Забыл дописать, что git push (при использовании ssh протокола) тупо вызывает ssh (или то, что прописано в переменной окружения GIT_SSH) с параметрами: Поэтому ни о какой аутентификации со стороны гита, а следовательно и о чтении всяких там конфигов, посвященных аутентификации не может быть и речи.
P.P.S. Может быть у вас какой-нибудь гитовый гуй такой фигней с кешированием паролей страдает?
bormand 02.02.2013 08:59 # 0
bormand 02.02.2013 09:25 # 0
P.S. А есть ли смысл юзать запароленную HTTP/HTTPS репу? Имхо корячить WebDAV ради пуша в нее это намноого большее извращение чем gitolite/gitosis.
wvxvw 02.02.2013 12:03 # 0
Зачем нужно задавать пароли в файлах настроек Гита: предположим, у вас на одном сервере есть репозитории с разными логинами/паролями, тогда настройки SSH не достаточно специфические.
bormand 02.02.2013 13:25 # 0
Эм. Не знал о такой возможности. Можно ссылку на ман, где описывается подобная настройка?
bormand 02.02.2013 13:31 # 0
defecate-plusplus 02.02.2013 13:42 # +4
wvxvw 02.02.2013 13:42 # 0
Вот тут описан механизм, только вместо user@repository используйте user:password@repository схему.
roman-kashitsyn 02.02.2013 13:50 # +1
wvxvw 02.02.2013 14:28 # +1
roman-kashitsyn 02.02.2013 14:53 # 0
> и есть репозиторий, в котором, ну я не знаю... я разрабатываю порносайт?
Мы начали с того, что у вас уже два репозитория, и есть желание, чтобы один из них никто не ассоциировал с вами и, желательно, не видел. При чём здесь сомнительные проблемы с разными паролями для одного пользователя на одном и том же хосте?
wvxvw 02.02.2013 15:26 # 0
bormand 02.02.2013 15:33 # 0
Ну для создания вашей схемы, в том же гитолайте можно сгенерить по ключу на каждую репу, и выставить этому ключу право на доступ только к своей репе.
bormand 02.02.2013 13:55 # 0
bormand 02.02.2013 14:04 # 0
wvxvw 02.02.2013 14:31 # 0
bormand 02.02.2013 14:46 # 0
roman-kashitsyn 02.02.2013 14:59 # 0
bormand 02.02.2013 15:03 # +2
Кстати, в том же гитолайте можно мудаку-фрилансеру поставить R доступ на master и W доступ на их личную ветку. А мерджить самому, заодно просматривая чего они там наворотили. И овцы сыты, и волки целы.
wvxvw 02.02.2013 15:30 # 0
bormand 02.02.2013 15:40 # 0
О боже... git describe же. Показывает для коммита версию в виде 1.0-37-g86c283a, где 1.0 - последний тег, навешанный перед текущим коммитом, 37 - количество нетегированных коммитов после того самого тега. 86c283a - кусок айдишки коммита. Чем не хронология?
roman-kashitsyn 02.02.2013 15:42 # +2
scriptin 02.02.2013 15:47 # 0
wvxvw 02.02.2013 15:51 # 0
roman-kashitsyn 02.02.2013 15:59 # 0
scriptin 02.02.2013 16:01 # +1
После ваших примеров мне вспоминается это: "Я стою на асфальте, в лыжи обутый..."
wvxvw 02.02.2013 16:18 # 0
На практике, не зависимо от размера организации и внутреннего устройства, я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой. Любая организация, по своей сути является строгой иерархией, не допускающей разногласий в смысле порядка принятия решений, и в том числе связанных с тем, какой код она производит. Я работал в проектах типа САС, использующихся в Бритиш Эирлайнз и в стартапах из 2-3 человек. Нигде и никогда распределенная система версий ничего не улучшила. Иногда запутывала. Т.е. ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы. Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять и они занимают вцелом гораздо меньше места (Гит хранит всю историю проекта в каждой копии, в то время как централизованные системы хранят историю в одном центральном месте).
Чтобы лучше обьяснить это, приведу пример из САС-подобного проекта, где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер. С точки зрения админа Гит дублировал бы информацию на одном и том же физическом сервере. Т.е. заявленная "надежность" на практике была бы фикцией, только увеличивавшей нагрузку на сеть и требования к обьему носителей информации.
scriptin 02.02.2013 23:03 # +1
Что это значит?
>Нужны именно версии, в хронологическом порядке
git log выводит в хронологическом в пределах ветки.
>я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой
Если вы работали с git, то сталкивались с DVCS - у каждого пользователя своя, независимая копия репозитория. Преимущество - отсутствие необходимости в сервере для того, чтобы работать с репозиторием, со всеми вытекающими плюсами. Мой коллега мне рассказывал о трудностях, которые у него возникали с svn, когда он работал удаленно - в тот раз пришлось поднимать наружный сервер.
>Любая организация, по своей сути является строгой иерархией
1. Не любая. Скорее наоборот: строгая иерархия является исключением. Христоматийные примеры организаций без иерархии: valve, 37signals. Бытовые примеры: любая маленькая компания, в которой иерархия весьма условна.
2. Даже если так, это не является аргументом против DVCS
>Нигде и никогда распределенная система версий ничего не улучшила.
А у меня улучшила. Deal with it.
>Иногда запутывала.
Цитата про лыжи выше.
>ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы.
Использовала. У каждого пользователя был свой репозиторий. См. выше.
>Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять
Не относящийся к вопросу аргумент. Дело админа - установить и настроить.
>и они занимают вцелом гораздо меньше места
Приведите цифры. По моим данным git гораздо компактнее хранит файлы репозитория.
>Гит хранит всю историю проекта в каждой копии
И это удобно и быстро.
>где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер
Это действительно хороший пример, где централизованные VCS имеют преимущество. К сожалению, для большинства компаний это слишком дорогое решение.
wvxvw 03.02.2013 01:07 # 0
Но про занимаемое место все-таки отвечу, т.как тут fail at reading comprehension. Гит хранит историю вместе с каждым репозиторием в то время как централизованые системы хранят историю только в одном месте. Как бы там Гит экономно ее не хранил, то при наличии более одного репозитория проиграет. А для компании с тысячами программистов это выливается в серьезные суммы. Когда я говорил с девушкой администрирующей билды / репозитори в Хьюлете, то она сказала, что по их подсчетам, им бы только на наш отдел пришлось бы купить еще две машины (т.как сотрудники получали каждый по ВМ для работы, и обьемы кода были такие, что пишлось бы по-другому разбивать дисковое пространство на уже имеющихся машинах, для того, чтобы Гит туда влез). Только над нашим проектом работало больше сотни человек (в нашем отделе - примерно десять). Итог - дешевле было бы купить хорошую систему версий, чем платить за железо для говенной, но бесплатной.
scriptin 03.02.2013 03:51 # +2
Вот цены на тот же perforce: http://www.perforce.com/purchase/pricing-licensing
При покупке за $480 на 100 человек имеем одноразовую трату в $48000. Самые дорогие HDD, которые я нашел, обойдутся в 20000 руб/Тб. На $48000 можно купить ~72Тб. В этот объем можно вместить 300-400 ТЫСЯЧ копий довольно больших git-проектов, то есть для исходных 100 человек имеем 3-4 тысячи репозиториев на брата.
Я не говорю, что из-за этого не стоит выбирать perforce, ведь у него наверняка есть множество преимуществ. Я также не утверждаю, что git - это лучший вариант. Я просто с ним лучше всего знаком.
wvxvw 03.02.2013 09:14 # 0
roman-kashitsyn 02.02.2013 11:41 # +1
Сорцы смотрел как-то ради интереса, никакого криминала не увидел. Обычный промышленный сишный код. Великов много, но это же pure Сишка, там такая библиотека, что свой велопарк приходится писать в любом проекте.
Багов за три года работы с git не наблюдал.
bormand 02.02.2013 11:47 # 0
Получается что не совсем. Для ssh, да, делегирует. А вот для HTTP/HTTPS он юзает cURL, и с паролями обращается самостоятельно (см. git-credential-cache).
> Багов за три года работы с git не наблюдал.
Плюсую.
P.S. Я видимо багов не наблюдал, т.к. за все время работы с гитом ни разу не пользовался http/https транспортом. Только ssh через гитолайт или ssh на гитхаб\битбакет.
bormand 02.02.2013 11:53 # 0
wvxvw 02.02.2013 12:07 # 0
То, что он "Юниксовая" программа, не помешало им так же встроить вовнутрь свой grep с блекджеком и шлюхами и еще много чего такого.
wvxvw 02.02.2013 14:21 # 0
Ну вот мне выдали в вотчину какой-то покрывшийся плесенью Центос, на котором нужно соорудить багтрекер + вики + репу + тестовый сервер + СиАй сервер и т.п. Сабвершн поставился без инцидентов за меньше чем 5 минут. Немножко повозился прикручивая его г Багзилле, но срослось в итоге. Гит - это такая феерическая муть по сравнению... Тоесть, вы не подумайте, я не сравниваю работу (хотя и там у меня есть нарекания), я просто говорю об интерфейсе программа-человек. В Гите политика не задумываться об удобстве разработчика, а следовать каким-то надуманным принципам. Настроить авторизацию (серверную часть) - это ад, бессмысленный и беспощадный. При чем, мне было бы не жалко, если бы это несло в себе какие-то бонусы. Так ведь нет. Те "улучшения", изза которых система становится более сложной - как раз та часть системы, которую нужно сразу же удалить и никогда не использовать.
Так, например, авторизация по буличным ключам компьютера недопустима в мало-мальски большой организации, особенно, если она позволяет пользователям доступ с домашних компьютеров.
roman-kashitsyn 02.02.2013 14:48 # 0
> В Гите политика не задумываться об удобстве разработчика
В гите политика думать, что ты делаешь, и знать, как он работает. Гибкость просто неимоверна, позволяется даже переписывать историю (rebase, squash), чего вроде бы не позволяет ни одна другая система управления ревизиями. Если использовать централизованную топологию, отличия от subversion минимальны.
Гит хранит не последовательность патчей, он хранит полную историю коммитов, знает, что, когда, как мёржилось. Это превращает мёржи в довольно тривиальную задачу (если работа была правильно распределена и конфликтов не много). Я, к примеру, трижды подумаю прежде, чем использовать ветку в subversion. В гите я даже думать не буду. А ведь у меня довольно богатый опыт мёржа веток в svn.
> если она позволяет пользователям доступ с домашних компьютеров
В чём проблема с доступом с домашних компьютеров по ключу?
Основная проблема с гитом - относительная сложность организации аутентификации, т.е. разделение прав. Эту проблему решают отдельные приложения вроде gitlab и gerrit.
bormand 02.02.2013 14:57 # 0
В том же самом, в чем и проблема с доступом с домашних компьютеров по паролю - в доступе с домашних компьютеров ;)
wvxvw 02.02.2013 15:41 # −1
Гит не хранит никакой истории, которую можно было бы осмысленно использовать. Он хранит массу информации, большая часть которой не представляет из себя никакой практической ценности. Это следствие его дибильного подхода к решению конфликтов, которые по-сути приходится решать в обход системы контроля версий.
Проблема в том, что домашний компьютер не находится под защитой корпоративного фаирвола и т.п. Если компутер сам, без содействия пользователя (т.е. помня пароль) может залогиниться в корпоративную сеть - это беда. Если такому пользователю сделать веб-авторизацию, то у него по крайней мере будет выбор: запомнить пароль / использовать менеджер парлолей, или тупо записать где-нибудь. В случае с авотизацией по публичным ключам - в мире может быть есть человек десять, способных запомнить свой публичный ключ. Остальные его будут просто записывать где-нибудь. Фрилансеры почти наверняка будут логинится из Виндовса - где никаких ограничений на доступ к их кючу не предвидится.
bormand 02.02.2013 15:52 # +1
А если пользователю сделать ключ - то у него тоже будет выбор - сгенерить ключ без пароля, либо сгенерить ключ с паролем, и записать этот пароль, либо сохранить в менеджере паролей (аля ssh-agent).
Проблема то совсем не в ключах и паролях. Вы серьезно считаете, что трояну, сидящему на компе того самого фрилансера, ключ угнать легче чем спиздить пароль вводимый юзером с бумажки? Да это абсолютно равнозначные по сложности действия.
roman-kashitsyn 02.02.2013 15:54 # +1
История в git ничем не хуже, чем в subversion, даже лучше, ибо хранит больше информации. Например, путём слияния каких коммитов был получен мёрж. Конфликты решаются практически также, как и в svn, впрочем, практически в любом VCS мёрж конфликтов есть тёмная магия и у неопытных пользователей вызывает ступор.
> в мире может быть есть человек десять, способных запомнить свой публичный ключ
Нафига запоминать публичный ключ? Он на то и публичный, чтобы его все знали. Он не предоставляет никакой ценности. По-настоящему важен закрытый ключ, и он обычно генерится с правами доступа 600, чтобы кроме создателя его никто открыть не мог. И обычно его стараются либо переносить на защищённом носителе информации, либо генерить для каждого компьютера заново.
bormand 02.02.2013 16:01 # +1
С гитом же ситуация намного лучше - можно коммититься сколько душе угодно, можно откатывать изменения, если что-то не то натворил. И, закончив логически осмысленный кусок (пофиксив баг, запилив небольшую фичу), можно смерджить свои изменения с матстером и запушить их.
roman-kashitsyn 02.02.2013 16:07 # 0
wvxvw 02.02.2013 16:36 # −1
С Сабвершном - это вполне известная неприятность - очень затрудниетельно в любом виде отойти от основной рабочей версии. Как правило это нужно / приходится делать с разрешения / в присутствии админа. Но это правильно! Т.как программист не должен плодить версии безконтрольно, потому что этим он создает проблемы административного порядка, которые решать уже не ему. У Сабвершна нет такого понятия как "локальная история", поэтому тут и сравнивать бессмысленно, но если сравнивать с Перфорсом, то там это удобнее, чем в Гите, и ничего вообще не переписывается, т.как этот процесс не связан напрямую с историей всего репозитория.
> Вы серьезно считаете, что трояну [...]
Тут даже не про трояны речь. Если авторизируется компьютер, то любой, кто воспользуется этим компьютером без вообще каких либо усилий сможет авторизироваться. Это как разница между открытой дверью и дверью закрытой на амбарный замок. Амбарный замок просто сломать, имея инструменты, но все таки мы считаем такую дверь более защищенной.
bormand 02.02.2013 18:35 # 0
Но в любом случае, даже если кто-то злой имеет доступ к компу горе-фрилансера, то что он сделает получив доступ только к гитовой репе (которую вы, как вы написали выше, выделили специально для этого фрилансера)? Все, что он сможет сделать - закоммитить туда какую-нибудь злую херню... Но вот с тем же успехом он может внести эту херню ему в локальную копию, не имея никаких ключей и паролей, а тот не заметив подвоха закоммитит ее сам...
P.S. С перфорсом вживую не встречался, но посмотреть давно хочу. Надо будет попробовать поюзать его на каком-нибудь небольшом но реальном проекте.
roman-kashitsyn 02.02.2013 18:47 # 0
Не знаю, нужно ли оно, когда вокруг столько бесплатных простых инструментов с отличной документацией.
wvxvw 02.02.2013 21:14 # −1
Вобщем, типичное необдуманное позерство и groupthink, которого везде и всегда полно.
roman-kashitsyn 02.02.2013 23:52 # +2
Это уже слишком толсто. А с виду ты худенький
scriptin 02.02.2013 23:57 # +1
roman-kashitsyn 03.02.2013 00:03 # +3
Перефразирую Классика
"There are only two kinds of technologies: the ones wvxvw complains about and the ones nobody uses."
wvxvw 02.02.2013 16:24 # −4
bormand 02.02.2013 19:00 # 0
С опцией M ваша история станет линейной и шелковистой.
wvxvw 02.02.2013 20:54 # 0
bormand 02.02.2013 21:01 # 0
Если ваш перфорс такой удобный и хороший почему вы не убедили своих программистов его юзать?
P.S. Если в гитолайте включены RW+M у админа и RW у программистов, то история линейная, менять ее без помощи админа нельзя, что же вам еще нужно ;)
wvxvw 02.02.2013 21:32 # 0
Я один, а их много... люди, как правило не пытаются самостоятельно анализировать: что всплыло в Гугле с большим счетчиком - то и используют. Ни в одном месте, где я работал, за исключением того, где использовался Перфорс, люди либо ничего кроме Сабвершн никогда не видели, либо это был выбор между Сабвершн и Гит. Но дело даже не в этом. Перфорс - коммерческий. И если уже быть до конца откровенным, то тут у некоторых иногда даже Виндовса лицензионного нет, а о том, чтобы взять коммерческий продукт вместо популярного бесплатного, каким бы хорошим он ни был... честно, я бы тоже взял что-то бесплатное. :( Но я бы смотрел в сторону Базара, т.как написано на Питоне и его просто интегрировать с билд скриптами (если они тоже на Питоне), и с Си-Ай скриптами, если они тоже на Питоне, и с еще кучей всего, что тоже может случайно быть написано на Питоне...
bormand 02.02.2013 18:48 # 0
Ок. Пишем в конфиге гитолайта обычным программистам RW, админу RW+. Выдыхаем.
roman-kashitsyn 02.02.2013 18:59 # +2
Далее. Из речей @wvxvw складывается ощущение, что админы - существа гораздо более глубокомысленные и знающие, чем программисты. По моему опыту они обычно ленивее и лучше противостоят нововведениям, ведь если что сломается, иметь будут их, и я ничего не имею против. Ещё они иногда лучше разбираются в железках и знают, что где лежит, и как оно включается. Но менять историю в репозитории я бы своим админам не доверил.
Так что единственный мотив давать права на изменение истории админам - тот факт, что она им абсолютно неинтересна, и они в неё никогда не полезут.
bormand 02.02.2013 19:05 # 0
Я так понял, что админ править историю будет только тогда, когда к нему прибегут программисты, и объяснят начерта им надо ее менять. Я думаю в остальное время ему будет просто лень копаться в проекте, у админов и без этого другой работы полно. А права админу, управляющему репой не помешают, т.к. иначе ему придется их выдать самому себе, когда возникнет критическая ситуация.
bormand 02.02.2013 19:33 # 0
wvxvw 02.02.2013 20:52 # 0
3.14159265 04.02.2013 16:26 # +5
wvxvw против gita.
От создателей В js скушное ооп и Некошерный эрланг.
Смотрите этой зимой на говнокоде.
Лично мне эта часть показалась скушной и избитой. Актерская игра никакая. Сплошная толстота.
3.14159265 04.02.2013 16:37 # 0
fix
eth0 04.02.2013 17:16 # 0
Соглашусь, срач вышел унылый. И возник на пустом месте.
Возвращаясь к основному обсуждению. Само собой, опять даты, опять PHPSQL, но я почему-то пошёл против общественного мнения. Как много иррационального в наших поступках. Хотелось бы услышать мнение ещё троих.