форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
Сообщение от opennews (??) on 16-Июл-16, 21:59
Доступен (http://www.lighttpd.net/2016/7/16/1.4.40/) релиз легковесного http-сервера lighttpd 1.4.40 (http://www.lighttpd.net), в котором закрыто 157 отчётов об ошибках и представлено несколько улучшений. Одновременно сообщается о переходе проекта с централизованной системы управления версиями Subversion на Git. Основные изменения: -  Улучшено управление ресурсами: ограничено потребление памяти при обработке больших запросов, в динамических бэкендах реализована поддержка асинхронных двунаправленных потоков и определения разрыва соединения клиентом; -  Реализован откат на традиционные средства ввода/вывода при отсутствии поддержи mmap и sendfile; -  Обновлена поддержка lua 5.2, 5.3; memcached; libressl; openssl 1.1.0; -  Улучшена поддержка cygwin; -  Расширена поддержка  webdav; -  При запуске "lighttpd -tt" теперь выполняется  проверка корректности файла конфигурации; -  Добавлена опция "-1" при которой lighttpd выполняет один запрос из входного потока и завершает работу (например, можно использовать для запуска из inetd); -  Добавлена опция "-i" для завершения работы в случае определённого периода неактивности; -  В файлах конфигурации обеспечена возможность включения группы файлов по маске (например include "conf.d/*.conf"); -  Для CGI и SCGI реализована поддержка заголовка X-Sendfile (https://tn123.org/mod_xsendfile/); -  В mod_cgi реализована обработка локальных пробросов через заголовок Location для путей вида "/path?query"; -  Переменная окружения REDIRECT_URI теперь выставляется для и для внутренних редиректов (cgi, magnet, rewrite, errdoc); -  Переменная окружения REDIRECT_STATUS в которой устанавливается код статуса редиректа; -  Новые директивы: -  server.bsd-accept-filter ("httpready", "dataready") -  server.error-handler для задания обработчиков кодов состояния 4xx и 5xx; -  server.http-parseopt-header-strict для ограничения символов, допустимых в HTTP-заголовках; -  server.http-parseopt-host-strict для ограничения символов, допустимых в HTTP-заголовке  Host; -  server.http-parseopt-host-normalize для включения нормализации содержимого HTTP-заголовка  Host; -  server.listen-backlog для настройки параметра backlog для сокета и listen-backlog для FastCGI и SCGI; -  Директива server.max-request-size теперь может применяться в других блоках (ранее применялась только как глобальная настройка); -  server.stream-request-body для управления буферизацией запроса; -  server.stream-response-body для управления буферизацией ответа; -  В accesslog.format добавлена поддержка мароподстановок %a %A %C %D %k %{}t %{}T. URL: http://blog.lighttpd.net/articles/2016/07/16/lighttpd-1.4.40.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=44797
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
Сообщение от Аноним (??) on 16-Июл-16, 21:59
кто-то его ещё использует?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 16-Июл-16, 22:02
	svn или lighttpd? да никто как и hg. Исторические установки lighttpd разве...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от rm_ (ok) on 16-Июл-16, 22:16
	Отож. В настройке гораздо логичнее и приятнее nginx'а.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	30. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 17-Июл-16, 19:53
	> Отож. В настройке гораздо логичнее и приятнее nginx'а. Один бывший майнтейнер лайти в альте споткнулся о проблемы при отдаче файлов с плюсом в имени (уже давно исправлено, помнится) -- посмотрел в код, ужаснулся и перестал это применять/поддерживать...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	36. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–2 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:11
	С другой строны - безбашенный хипстерский проект. Управляется по студенчески, имеет ряд технических проблем, которые в этом столетии никуда не денутся, развитие встало, мифическая версия 2.0 вообще случится наверное не раньше повсеместного пришествия коммунизма. Так то вариант, но без каких либо изюминок.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	51. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от rm_ (ok) on 19-Июл-16, 19:09
	> развитие встало Потому что он просто работает, делает всё что нужно и делает это хорошо. А какая-то там "2.0", и переписывать под неё все конфиги на Луа? Даром не надо, тогда уж проще будет действительно на нгинкс перейти.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	57. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 25-Июл-16, 11:22
	> Потому что он просто работает, делает всё что нужно и делает это хорошо. Только отгрузку статики, только по HTTP/1.1 и без проксирования. > А какая-то там "2.0", и переписывать под неё все конфиги на Луа? Да там вообще какие-то планы олдскульных хипстеров. Я думаю что они это не релизнут за ближайшие 10 лет. Было время когда их market share был 3-й в мире, проигрывая только IIS и Apache. Они это прошляпили. Зато подсуетился nginx. > Даром не надо, тогда уж проще будет действительно на нгинкс перейти. Он технически лучше в проксировании, умеет HTTP/2 и кэширование. Но более сложный и комбайнообразный. И в начинке и в настройке.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	10. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–2 +/–
	Сообщение от Аноним (??) on 16-Июл-16, 23:42
	Арчефилы любят это https://wiki.archlinux.org/index.php/lighttpd
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	12. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–3 +/–
	Сообщение от Аноним (??) on 17-Июл-16, 01:18
	Арчеры испытываюст яростную ненависть при виде lighttpd
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	37. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:12
	> Арчеры испытываюст яростную ненависть при виде lighttpd Предыдущие анонимы многовато на себя берут, расписываясь за всех.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	13. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–2 +/–
	Сообщение от Аноним (??) on 17-Июл-16, 01:19
	> Арчефилы любят это > https://wiki.archlinux.org/index.php/lighttpd Скобочки и вся эта лишняя хренотень не нужна как и lighttpd.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+2 +/–
	Сообщение от Гога Гитов on 17-Июл-16, 01:33
	> кто-то его ещё использует? да. весит меньше, чем апач. умеет cgi-bin. умеет /~username
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	33. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от 71349560 on 18-Июл-16, 13:24
	> кто-то его ещё использует? проксировал seafile для https.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	38. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:14
	> проксировал seafile для https. Теперь качни файлик гигз на 20 и посмотри на потербляемую lighttpd память. Нет, системе он это больше не отдаст. К вопросу зачем nginx развел в своих внутренностях такую мощную канитель с chunk'ами и responce chain.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

3. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+3 +/–
Сообщение от увася on 16-Июл-16, 22:14
llvm/clang еще на svn и это позор
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+4 +/–
	Сообщение от anonymous (??) on 16-Июл-16, 22:37
	Можно подумать, переход на git что-то изменит.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	39. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:17
	> llvm/clang еще на svn и это позор И gcc тоже. Сапожники без сапог.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	58. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от anonymous (??) on 01-Авг-16, 14:30
	>Сапожники без сапог. Лолшто? Это если бы git разрабтывали в svn, был бы сапожник без сапог.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

7. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+2 +/–
Сообщение от Аноним (??) on 16-Июл-16, 22:39
Эээ... А он точно "light"?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от Унывай Душа Моя on 16-Июл-16, 23:51
	Полегче nginx.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 17-Июл-16, 04:56
	Упрлс?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	40. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:18
	> Полегче nginx. Очень зависит. Если лайти проксировать бэкэнд - он весь ответ бэкэнда целиком буферизует. И если бэкэнд отдаст 20 гигз, лайти внезапно станет вообще совсем не лайт.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Гога Гитов on 17-Июл-16, 01:38
	> Эээ... А он точно "light"? по сравнению с Апачем - да. намного.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	20. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июл-16, 08:59
	Кстати, жрёт рамы меньше, чем нжинкс.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 17-Июл-16, 19:41
	> Кстати, жрёт рамы меньше, чем нжинкс. И сказала Добрая Фея: "Вынь руки из ж.. ж... жЫнсов! вот! Вынь руки из жЫнсов, админ и настрой как тебе надо!" nginx то можно настроить на совсем крошечное потребление (только вот нафиг?!?!). Зато вот сабж никакими настройками до скорости нжЫнкса не дотянешь :-\ Я его пользовал как лёгкий бакэнд для нжинкса для CGI старья. Как оно кончилось - и сабж засох.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	41. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:20
	> Кстати, жрёт рамы меньше, чем нжинкс. Попробуй лайти попроксировать бэкэнды с жирными ответами, да? В нжинксе проблему обошли, сделав очень канительную систему с responce chain когда вся эта штука может по кусочкам ответ перекидывать. В лайти сделали как было проще - т.е. буферизацию всего ответа. И если ответ будет большим, лайти может заспорить даже с апачем.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

18. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
Сообщение от Аноним (??) on 17-Июл-16, 07:08
Очень рад, что разработчики наконец то освоили git
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от Нанобот (ok) on 17-Июл-16, 07:43
	Шило на мыло
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
Сообщение от A.Stahl (ok) on 17-Июл-16, 09:52
>Переход проекта с SVN на Git Блин, все валят на этот Git. Видимо и мне пора. Просто хотя бы чтобы не отстать от жизни. А ведь так лениво...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+2 +/–
	Сообщение от fail on 17-Июл-16, 12:12
	>>Переход проекта с SVN на Git > Блин, все валят на этот Git. Видимо и мне пора. Просто хотя > бы чтобы не отстать от жизни. А ведь так лениво... Ыыы, "ломка" будет суръёзная.. 2-5 дней, на освоение первого дана, а если без шуток, то "плюсов" гораздо больше
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–2 +/–
	Сообщение от bob (??) on 17-Июл-16, 15:59
	Zip-чиками с бекапами уже никто не пользуются?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	26. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июл-16, 17:44
	Там есть возможность "путешествовать" по коммитам?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	42. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:23
	> Zip-чиками с бекапами уже никто не пользуются? И каменные топоры не в ходу, только подумай.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	34. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 18-Июл-16, 17:47
	> а если без шуток, то "плюсов" гораздо больше name first two? Мне вот "плюсы" этого чудовища для нормальной группы разработчиков и нормальной разработки  совсем неочевидны. Ну, кроме, конечно, возможности вывалить все на гитхаб, забить на бэкапы и потерять все нафиг, когда гитхаб заболеет "монетизацией" или просто серьезно поломается. Оно автоматизирует задачу, которая могла возникнуть только у Линуса, с его катастрофическим неумением и нежеланием пользоваться вообще системами контроля версий.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	43. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:32
	1) Нормальный распределенный воркфлоу, когда никто никого не клинит. 2) Настолько, что пару коммитов можно нарисовать даже на природе и без интернета. 3) Это система контроля версий, а не файлменеджер или качалка. Оно хорошо, быстро и правильно упрвляет версиями. Не требуя качать терабайты на вытаскивание каждой ревизии из загашника. 4) Поэтому можно за полчаса сделать git bisect найдя где был порыт проблемный баг. Попробуй так с svn и сравни. Ну а нормальная группа разработчиков - это как раз Торвальдс с его командой. Ты к нему и близко не стоял, вместе со своей командой лузеров. У него большая, географически распределенная команда. Чертовски эффективная - у них очень большой проект, который очень быстро разрабатывается и что особенно эпично - все это еще и работает потом. Учить их правильныму workflow будешь сразу после обучения Гейтса заработкам, Шумахера - вождению, а Кнута - программированию.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	45. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 18-Июл-16, 20:49
	> 1) Нормальный распределенный воркфлоу, когда никто никого не клинит. ну ты так можешь даже вообще без vcs, только результатом будет два (или больше) параллельных проекта. Которые потом один хрен мержить с кровью и кишками. Клинит -то тебя не vcs, а реальное отсутствие/поломанность/несоответствие реального кода, который кто-то, не ты, должен еще пере/написать. > 2) Настолько, что пару коммитов можно нарисовать даже на природе и без интернета. но зачем? В нормальной, опять же, ситуации - либо ты почти единственный разработчик (хотя бы своего куска), либо без code review все равно не примут - поэтому нарисованное на природе вполне можно и в working copy оставить. для linux kernel - да, критично, "большой" (смехотворно) патч не примут вообще. Ну так это проблемы коммитеров в линукскернел - зачем вот оно авторам clang, которых по пальцам одной руки пересчитать? > Это система контроля версий, а не файлменеджер или качалка. Оно хорошо, быстро и > правильно упрвляет версиями. Не требуя качать терабайты на вытаскивание каждой ревизии > из загашника. требуя хранить все терабайты локально, с момента сотворения мира, ага. Кстати, по этой самой причине, качалка-то там как раз вполне себе ничего так, не знаю, где еще более продвинутая. Но опять же - если ты не коммитер ядра, нафиг оно тебе? > 4) Поэтому можно за полчаса сделать git bisect найдя где был порыт проблемный баг. > Попробуй так с svn и сравни. сравнивал - когда это не твой проект - с svn оно вышло гораздо проще. Хотя и с единственным инструментом в виде blame (и без понятия, blame что). > Ну а нормальная группа разработчиков - это как раз Торвальдс с его командой. сочувствую... Рассказать тебе про историю linux-net team времен ank@? Которые использовали svn во времена когда у Линуса основным рабочим инструментом был pine (или что там - помню что что-то ужасное) и patch? К счастью, Линусу ну уже очень надо было работающую сеть, а другой вменяемой команды не предвиделось ( и нынче нету). > Ты к нему и близко не стоял, вместе со своей командой лузеров. ну значит мне git и не нужен, как, собственно, и большинству,да. Ну нету у меня задачи автоматизировать приляпывание патчей из почтового клиента. А исходная идея git как раз в этом и состояла.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	52. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 19-Июл-16, 20:16
	> ну ты так можешь даже вообще без vcs, только результатом будет два > (или больше) параллельных проекта. Которые потом один хре н мержить с кро вью и ки шками. Дай чудаку стеклянный Х - он и Х разобьет и руки порежет. Весь пойнт в том чтобы каждый пилил свою фичу условно-независимо и не лез в чужие огороды без нужды. А если влез - оформлял мержабельно. > Клинит -то тебя не vcs, а реальное отсутствие/поломанность/несоответствие реального кода, > который кто-то, не ты, должен еще пере/написать. В случае git обычно применяются workflow, когда пилят и мержат "фичу", а место где народ координирует усилия - консистентно. У свинарей то полурабочая фича в проекте то гемор у разработчика - нормально управлять историей не получается. А в гите можно все и сразу. Более того, в гите можно организовать нормальный preview фичи из бранча вон того разработчика, куда более вменяемо чем бранчи в свине, которые в свине бесполезны. Свин к тому же не масштабируется и нагружает PM/мержера по поводу и без. >> 2) Настолько, что пару коммитов можно нарисовать даже на природе и без интернета. > но зачем? В нормальной, опять же, ситуации - либо ты почти единственный > разработчик (хотя бы своего куска), А затем что пришло удачное решение - записал. А через 2 дня поздняк метаться, все забудешь уже. > либо без code review все равно не примут - поэтому нарисованное на природе > вполне можно и в working copy оставить. Только с гитом у человека нормальный контроль версий под рукой. Он и коммитить может, и локальные бранчи создавать, и по ревизиям шариться, не только своим, а если баг вылез то и bisect устроить, по всему проекту. Не перекачивая весь проект 20 раз с жуткими тормозами. > для linux kernel - да, критично, "большой" (смехотворно) патч не примут вообще. У Linux kernel налажены разумные и эффективные воркфлоу для большого проекта с большой командой, даже распределенной. Корпорашки стали просекать и так смешно тужатся это содратью. Что только не придумали со всякими скрам-бананами. > Ну так это проблемы коммитеров в линукскернел - зачем вот оно > авторам clang, которых по пальцам одной руки пересчитать? Во первых, их побольше. Во вторых, у них есть гит-зеркало и многие из - давно орудуют гитом, чтобы хоть немного скрасить паршивость svn как системы контроля версий. В третьих, паршивые девтулсы не способствуют пополнению рядов разработчиков. А svn плохой девтул, потому что управление версиями никакущее. > требуя хранить все терабайты локально, с момента сотворения мира, Во первых, хранятся эффективно, с дельтами и сжатием. Так что сжатое хранилище у линуха весит примерно как 1-2 распакованных версии ядра. Только там вообще все, начиная с 2.6.9, чтоли. И всегда можно сгонять на машине времени назад в момент когда бага возможно еще не было. Во вторых, никто ничего не требует - клонируй с depth=1 и будет тебе репа как у svn. Но это глупо, если планируется сколь-нибудь активная работа с проектом. Этим обычно страдают адепты клуба "вступайте и кампелируйте". Об их удобстве разработчики не заботятся, разумеется. Разработчики о своем удобстве заботятся. > Кстати, по этой самой причине, качалка-то там как раз вполне себе ничего > так, не знаю, где еще более продвинутая. Качалка умеет дельты, но докачку не умеет. Поэтому на начальный синк может потребоваться поднапрячься, но дельты потом качать можно хоть GPRS. Вот разработчики и не напрягаются, раз в жизни нужный проект можно на толстом канале утащить. > Но опять же - если ты не коммитер ядра, нафиг оно тебе? А затем, что когда я вкатил в мои системы новое ядро и что-то отвалилось (у меня встройка, не тестируется на хомяках) - делаю git bisect и быстро вывожу баг на чистую воду. Как минимум regressions и newly introduced. А когда проблема вычислена - маневрировать просто. Остальные варианты поимки ядерных багов сильно затратнее. > сравнивал - когда это не твой проект - с svn оно вышло гораздо проще. > Хотя и с единственным инструментом в виде blame (и без понятия, blame что). Свин на каждый чекаут перекачивает полинтернета и вообще тормозит. Поэтому получается все это медленно и печально. Если система контроля версий плохо контролирует версии - зачем она нужна? > сочувствую... Yolo, it WORKSFORME. For fun and profit. > Рассказать тебе про историю linux-net team времен ank@? Которые использовали svn во > времена когда у Линуса основным рабочим инструментом был pine А зачем мне все эти истории наскальной живописи? > ну уже очень надо было работающую сеть, а другой вменяемой команды > не предвиделось ( и нынче нету). Ну а Линус вот еще своим соратникам нормальную vcs подогнал на нормальных условиях. И чего-то все пользоваться стали, в том числе и далеко за пределами ядра. Гитхаб и прочие гитлабы, центрированные на работу с сорцами а не файлокачание быстренько задвинули всякие сорсфоржи, где кроме файлопомойки и нет ничего вменяемого, а разработчикам файлопомойки как собаке пятая нога. >> Ты к нему и близко не стоял, вместе со своей командой лузеров. > ну значит мне git и не нужен, как, собственно, и большинству,да. Про большинство ты прав - они программить не умеют. Зачем им vcs? Версионировать фоточки котят? Лол, там одна версия, она же финальная. > Ну нету у меня задачи автоматизировать приляпывание патчей из почтового клиента. А > исходная идея git как раз в этом и состояла. На самом деле это всего лишь один из множества вариантов обмена патчами. Есть и ряд других, на все случаи жизни - от флоппинета до гитхаба. Гит как таковой ничего жестко не навязывает. Где на гитхабе и прочих гитлабах патчи в емыле, чудак? Гит можно хоть по RFC1149 использовать. Оформил package, прикрутил - и полетели патчи! :)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	55. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+2 +/–
	Сообщение от Аноним (??) on 20-Июл-16, 17:56
	> один хрен мержить с кровью и кишками Вот по этому вангую полный бардак в процессее разработки. > требуя хранить все терабайты локально, с момента сотворения мира А по этому —  отсутствие каких-либо практических знаний о Git. Думаю, в этом и причина твоих неолуддитских настроений. Практически любой современный DVCS лучше svn по удобству работы для конечного пользователя и по всей той помощи, которую современный DVCS готов предложить разработчику, будь это скрипт на 100 строчек или проект уровня Linux Kernel.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	47. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от fail on 18-Июл-16, 23:55
	>> а если без шуток, то "плюсов" гораздо больше > name first two? в порядке историческо сложившемся, 1. использованию дискового по сравнению с svn:   небольшой, стендовый вспомогательный проект,   один из, от (Date:   Mon Jan 25 13:40:08 2016)   2-3 ветки и т.п.,   user@desktop .build$ git log | grep commit\ | wc -l   664      project            - 110 M   --------------------------   project/.git       - 9.6 M =>   project/src/.build - 88  M => здесь результат сборки   project/src/res    - 1.4 M => небольшой набор bin data   project/src/*      - ??? M => текстовка    2. "история" всегда под "боком" 3. механизм diff`ов ... N > Мне вот "плюсы" этого чудовища для нормальной группы разработчиков и нормальной разработки >  совсем неочевидны. > Ну, кроме, конечно, возможности вывалить все на гитхаб, забить на бэкапы и > потерять все нафиг, когда гитхаб заболеет "монетизацией" или просто серьезно поломается. звиняйте, но не только лишь все используют гитхаб или gitlab, бывает и свои мощности используют > Оно автоматизирует задачу, которая могла возникнуть только у Линуса, с его катастрофическим > неумением и нежеланием пользоваться вообще системами контроля версий. а кто этот доктор поставившей, этот страшный диагноз Линусу - ну там пруфы.. убег, наилучшего.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 19-Июл-16, 00:33
	> 1. использованию дискового по сравнению с svn: ну а где сравнение-то? И, кстати, что сравнивать - на сервере, на каждом сделавшем co/clone (или на _всех_ ;-), на сборочном тазу где svn export вполне бы хватило ? > 2. "история" всегда под "боком" ну, как и весь репо. Но не факт что это для многих проблема (у кого-то то и другое где-то в сети, и working copy тож) > 3. механизм diff`ов ну а тут чего интересного? Вот _не_ с точки зрения каких-то мегапроектов со странными особенностями, а чего-то вроде нашего покойного lighttpd (ну или clang даже) и возникающих там задач? > звиняйте, но не только лишь все используют гитхаб или gitlab, бывает и свои мощности > используют ну просто пользователи svn уже научилсь не доверять чужим сервисам, на горьком опыте, а пользователи git радостно бегут наступать на уже знакомые грабли. с точки зрения админа своих мощностей, даже не берусь определить, что противнее админить (многопользовательский и с разделением прав svn в любом своем протоколе та еще головная боль и геморрой, но и гит не лучше - если, конечно, тебе дороги твои пароли и твои пользователи) > а кто этот доктор поставившей, этот страшный диагноз Линусу - ну там пруфы.. пруфы для опоздавших родиться - в архивах lkml где-то между 99-м (когда все вменяемые люди уже использовали хотя бы cvs,и только великий Торвальдс шел своим путем с ручным прикладыванием миллиарда патчиков и tar.gz архивчиком) и 2002-м (когда из десятка вариантов был выбран самый уродливый, не просто проприетарный а налагающий совершенно безобразные требования на пользователей - но и это было для многих щастьем несказанным). Я, естественно, никому ничего доказывать не собирался и копий его истерик не сохранял.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	49. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от fail on 19-Июл-16, 09:26
	>> 1. использованию дискового по сравнению с svn: > ну а где сравнение-то? про сравнение никто и не говорил > И, кстати, что сравнивать - на сервере, на каждом сделавшем co/clone (или > на _всех_ ;-), на сборочном тазу где svn export вполне бы > хватило ? 1. про subdirs ".svn" значит уже не помним ? умнжаем size на два + служебка от svn + build и барабанная дробь... и все это добро без истории ( и веток ) 2. про комбинаторный "взрыв" догадываемся ? >> 2. "история" всегда под "боком" > ну, как и весь репо. Но не факт что это для многих > проблема (у кого-то то и другое где-то в сети, и working > copy тож) это кто как организует >> 3. механизм diff`ов > ну а тут чего интересного? Вот _не_ с точки зрения каких-то мегапроектов > со странными особенностями, а чего-то вроде нашего покойного lighttpd (ну или > clang даже) и возникающих там задач? лучше располагать возвможностями что-то сделать, чем не распол.. - разработчики поймут >> звиняйте, но не только лишь все используют гитхаб или gitlab, бывает и свои мощности >> используют > ну просто пользователи svn уже научилсь не доверять чужим сервисам, на горьком > опыте, а пользователи git радостно бегут наступать на уже знакомые грабли. ну если git(server) на не "локальном" хосте/VM/стораге - то ССЗБ > с точки зрения админа своих мощностей, даже не берусь определить, что противнее > админить (многопользовательский и с разделением прав svn в любом своем протоколе > та еще головная боль и геморрой, но и гит не лучше > - если, конечно, тебе дороги твои пароли и твои пользователи) думается разговор шел по линии "разраба" >> а кто этот доктор поставившей, этот страшный диагноз Линусу - ну там пруфы.. > пруфы для опоздавших родиться - в архивах lkml где-то между 99-м (когда > все вменяемые люди уже использовали хотя бы cvs,и только великий Торвальдс > шел своим путем с ручным прикладыванием миллиарда патчиков и tar.gz архивчиком) > и 2002-м (когда из десятка вариантов был выбран самый уродливый, не > просто проприетарный а налагающий совершенно безобразные требования на пользователей > - но и это было для многих щастьем несказанным). Я, естественно, > никому ничего доказывать не собирался и копий его истерик не сохранял. Как мы были Йуны и Глупы.. История та помнится, тут локальный переезд сорцов c svn на гит, механизм и концепцию менять пришлось в течении полугода, а там все было сделано для себя и в лучшем виде ... Кстати, народ из геймдева после тяжелых войн между отделами, определился со схемой использования этих двух vcs: - snv: binary asset(s) - git: source code Локальный Опыт подтвердил разумность схемы, Откланяюсь
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	53. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 20-Июл-16, 04:02
	На самом деле, главный плюс распределенной системы в том, что с svn-ом надо нормальный канал с сервером, а с гитом можно спокойно работать в офлайне или с дерьмовым мобильным интернетом. Скажем, посиживая на берегу моря. Для меня, по крайней мере, главный. Офисному планктону особо без разницы, думаю.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	54. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от пох on 20-Июл-16, 14:31
	> а с гитом можно спокойно работать в офлайне или с дерьмовым мобильным интернетом. ниасилили терминальный доступ? > Для меня, по крайней мере, главный. Офисному планктону особо без разницы, думаю. еще бывают клепатели не для себя, любимого. При этом я-то могу быть и на берегу моря - у меня один хер что на берегу, что в офисе - терминал. Тащить на берег моря то, что может это скомпилировать, мне тяжеловато, а то что может тестировать - вообще только aircargo. В виду того, что запускать потом все равно надо не на любимом планшетике, а на не совсем даже pc-архитектуре и с нетранспортабельной мощностью. Если у этой штуки отвалится коннективити- у нее будут совсем другие проблемы, про проблему недоступности репозитория уже и вспоминать будет некогда (да и сборка там тоже distributed). линуксописателям - тем да, у них вся жизнь в написании нового ведра чтобы на нем скомпилить еще более новое ведро, и физическую доступность кнопки ресет подавай.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

24. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–2 +/–
Сообщение от ALex_hha (ok) on 17-Июл-16, 14:11
А чтобы начать более менее нормально и комфортно работать, надо будет 2-5 месяцев
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от dgdsgfsadfgsdfgsdfg on 17-Июл-16, 18:55
	Им надо пользоваться, а не работать.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

32. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
Сообщение от ALex_hha (ok) on 18-Июл-16, 11:46
ну если ты админишь локалхост, то да, можно просто пользоваться, а не работать :D
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	–1 +/–
	Сообщение от . on 18-Июл-16, 17:51
	> ну если ты админишь локалхост, то да, можно просто пользоваться, а не > работать :D даже если локалхост - то все равно может понадобится работать - когда нужно не побыстрому clone/make/rm -r, а найти, в какой момент чужой, плохо (или, чаще, никак) документированный проект поехал не в ту степь, выцарапать нужный айдишник и потом попытаться собрать работающую версию. Хотя бы даже работающую лично вот у тебя на локалхосте и один раз.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	44. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 19:41
	> ну если ты админишь локалхост, то да, можно просто пользоваться, а не работать :D У яндекса на лайти довольно серьезный локалхост помнится был - mirror.yandex.ru.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

46. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+2 +/–
Сообщение от ALex_hha (ok) on 18-Июл-16, 21:44
> даже если локалхост - то все равно может понадобится работать - когда нужно не побыстрому clone/make/rm -r, а найти, в какой момент чужой, плохо (или, чаще, никак) документированный проект поехал не в ту степь, выцарапать нужный айдишник и потом попытаться собрать работающую версию. Хотя бы даже работающую лично вот у тебя на локалхосте и один раз. об этом я и говорил, и чтобы это делать на автомате, а не на каждую команду открывать stackoverflow, надо больше 5 дней. Сужу по своему опыту, после 5 лет работы с svn переходить на git было не легко.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Переход проекта на..."	+/–
	Сообщение от Andrey Mitrofanov on 19-Июл-16, 10:17
	> об этом я и говорил, и чтобы это делать на автомате, а Не надо на автомате. Мозг используй. Чтоб мозг не сопротивлялся, посмотри кинцо с Торавльдсом:     http://www.opennet.dev/openforum/vsluhforumID9/7642.html#3     http://www.opennet.dev/openforum/vsluhforumID9/7808.html#3 ALL YR BAIS BELONG TWO US, YOUL BE ASSIMILATED. > не на каждую команду открывать stackoverflow, надо больше 5 дней. Сужу > по своему опыту, после 5 лет работы с svn переходить на > git было не легко. После git-а (нет, не 5 лет) svn st -u, ci $file и up просто мучительно болезненны, а искать "в гуглях" вообще нет никакой возможности.  Но кого ж волнуют мои трудности, да?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	56. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."	+1 +/–
	Сообщение от Аноним (??) on 20-Июл-16, 18:07
	> Сужу по своему опыту, после 5 лет работы с svn переходить на git было не легко. А по моему опыту после ** лет с RCS, CVS и SVN переходить на Git было не только легко и приятно, но ещё и очень быстро. За день перестроил workflow и переписал вспомогательные скрипты (на самом деле, больше выбросил, чем переписал). Потом постепенно перевёл все рабочие проекты на новую систему. О чём это говорит? О том, что личный опыт ни о чём не говорит. Кто-то после автошколы ездит 20 лет и ни одной аварии, а кто-то на первой же практике сносит газетный киоск. Тем не менее, Git сегодня, пожалуй, самый популярный DVCS, а значит он как минимум достаточно прост для освоения.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема