The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз 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_ email(ok) on 16-Июл-16, 22:16 
Отож. В настройке гораздо логичнее и приятнее nginx'а.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

30. "Релиз http-сервера lighttpd 1.4.40. Переход проекта с SVN на..."  +1 +/
Сообщение от Michael Shigorin email(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_ email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру