Доступен (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.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=44797
кто-то его ещё использует?
svn или lighttpd? да никто как и hg.Исторические установки lighttpd разве...
Отож. В настройке гораздо логичнее и приятнее nginx'а.
> Отож. В настройке гораздо логичнее и приятнее nginx'а.Один бывший майнтейнер лайти в альте споткнулся о проблемы при отдаче файлов с плюсом в имени (уже давно исправлено, помнится) -- посмотрел в код, ужаснулся и перестал это применять/поддерживать...
С другой строны - безбашенный хипстерский проект. Управляется по студенчески, имеет ряд технических проблем, которые в этом столетии никуда не денутся, развитие встало, мифическая версия 2.0 вообще случится наверное не раньше повсеместного пришествия коммунизма. Так то вариант, но без каких либо изюминок.
> развитие всталоПотому что он просто работает, делает всё что нужно и делает это хорошо.
А какая-то там "2.0", и переписывать под неё все конфиги на Луа? Даром не надо, тогда уж проще будет действительно на нгинкс перейти.
> Потому что он просто работает, делает всё что нужно и делает это хорошо.Только отгрузку статики, только по HTTP/1.1 и без проксирования.
> А какая-то там "2.0", и переписывать под неё все конфиги на Луа?
Да там вообще какие-то планы олдскульных хипстеров. Я думаю что они это не релизнут за ближайшие 10 лет. Было время когда их market share был 3-й в мире, проигрывая только IIS и Apache. Они это прошляпили. Зато подсуетился nginx.
> Даром не надо, тогда уж проще будет действительно на нгинкс перейти.
Он технически лучше в проксировании, умеет HTTP/2 и кэширование. Но более сложный и комбайнообразный. И в начинке и в настройке.
Арчефилы любят это
https://wiki.archlinux.org/index.php/lighttpd
Арчеры испытываюст яростную ненависть при виде lighttpd
> Арчеры испытываюст яростную ненависть при виде lighttpdПредыдущие анонимы многовато на себя берут, расписываясь за всех.
> Арчефилы любят это
> https://wiki.archlinux.org/index.php/lighttpdСкобочки и вся эта лишняя хренотень не нужна как и lighttpd.
> кто-то его ещё использует?да.
весит меньше, чем апач.
умеет cgi-bin.
умеет /~username
> кто-то его ещё использует?проксировал seafile для https.
> проксировал seafile для https.Теперь качни файлик гигз на 20 и посмотри на потербляемую lighttpd память. Нет, системе он это больше не отдаст. К вопросу зачем nginx развел в своих внутренностях такую мощную канитель с chunk'ами и responce chain.
llvm/clang еще на svn и это позор
Можно подумать, переход на git что-то изменит.
> llvm/clang еще на svn и это позорИ gcc тоже. Сапожники без сапог.
>Сапожники без сапог.Лолшто? Это если бы git разрабтывали в svn, был бы сапожник без сапог.
Эээ... А он точно "light"?
Полегче nginx.
Упрлс?
> Полегче nginx.Очень зависит. Если лайти проксировать бэкэнд - он весь ответ бэкэнда целиком буферизует. И если бэкэнд отдаст 20 гигз, лайти внезапно станет вообще совсем не лайт.
> Эээ... А он точно "light"?по сравнению с Апачем - да.
намного.
Кстати, жрёт рамы меньше, чем нжинкс.
> Кстати, жрёт рамы меньше, чем нжинкс.И сказала Добрая Фея: "Вынь руки из ж.. ж... жЫнсов! вот! Вынь руки из жЫнсов, админ и настрой как тебе надо!"
nginx то можно настроить на совсем крошечное потребление (только вот нафиг?!?!).
Зато вот сабж никакими настройками до скорости нжЫнкса не дотянешь :-\
Я его пользовал как лёгкий бакэнд для нжинкса для CGI старья. Как оно кончилось - и сабж засох.
> Кстати, жрёт рамы меньше, чем нжинкс.Попробуй лайти попроксировать бэкэнды с жирными ответами, да? В нжинксе проблему обошли, сделав очень канительную систему с responce chain когда вся эта штука может по кусочкам ответ перекидывать. В лайти сделали как было проще - т.е. буферизацию всего ответа. И если ответ будет большим, лайти может заспорить даже с апачем.
Очень рад, что разработчики наконец то освоили git
Шило на мыло
>Переход проекта с SVN на GitБлин, все валят на этот Git. Видимо и мне пора. Просто хотя бы чтобы не отстать от жизни. А ведь так лениво...
>>Переход проекта с SVN на Git
> Блин, все валят на этот Git. Видимо и мне пора. Просто хотя
> бы чтобы не отстать от жизни. А ведь так лениво...Ыыы, "ломка" будет суръёзная.. 2-5 дней, на освоение первого дана,
а если без шуток, то "плюсов" гораздо больше
Zip-чиками с бекапами уже никто не пользуются?
Там есть возможность "путешествовать" по коммитам?
> Zip-чиками с бекапами уже никто не пользуются?И каменные топоры не в ходу, только подумай.
> а если без шуток, то "плюсов" гораздо большеname first two?
Мне вот "плюсы" этого чудовища для нормальной группы разработчиков и нормальной разработки совсем неочевидны.
Ну, кроме, конечно, возможности вывалить все на гитхаб, забить на бэкапы и потерять все нафиг, когда гитхаб заболеет "монетизацией" или просто серьезно поломается.Оно автоматизирует задачу, которая могла возникнуть только у Линуса, с его катастрофическим неумением и нежеланием пользоваться вообще системами контроля версий.
1) Нормальный распределенный воркфлоу, когда никто никого не клинит.
2) Настолько, что пару коммитов можно нарисовать даже на природе и без интернета.
3) Это система контроля версий, а не файлменеджер или качалка. Оно хорошо, быстро и правильно упрвляет версиями. Не требуя качать терабайты на вытаскивание каждой ревизии из загашника.
4) Поэтому можно за полчаса сделать git bisect найдя где был порыт проблемный баг. Попробуй так с svn и сравни.Ну а нормальная группа разработчиков - это как раз Торвальдс с его командой. Ты к нему и близко не стоял, вместе со своей командой лузеров. У него большая, географически распределенная команда. Чертовски эффективная - у них очень большой проект, который очень быстро разрабатывается и что особенно эпично - все это еще и работает потом. Учить их правильныму workflow будешь сразу после обучения Гейтса заработкам, Шумахера - вождению, а Кнута - программированию.
> 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 как раз в этом и состояла.
> ну ты так можешь даже вообще без 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, прикрутил - и полетели патчи! :)
> один хрен мержить с кровью и кишкамиВот по этому вангую полный бардак в процессее разработки.
> требуя хранить все терабайты локально, с момента сотворения мира
А по этому — отсутствие каких-либо практических знаний о Git.
Думаю, в этом и причина твоих неолуддитских настроений. Практически любой современный DVCS лучше svn по удобству работы для конечного пользователя и по всей той помощи, которую современный DVCS готов предложить разработчику, будь это скрипт на 100 строчек или проект уровня Linux Kernel.
>> а если без шуток, то "плюсов" гораздо больше
> 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, бывает и свои мощности используют
> Оно автоматизирует задачу, которая могла возникнуть только у Линуса, с его катастрофическим
> неумением и нежеланием пользоваться вообще системами контроля версий.а кто этот доктор поставившей, этот страшный диагноз Линусу - ну там пруфы..
убег, наилучшего.
> 1. использованию дискового по сравнению с svn:ну а где сравнение-то?
И, кстати, что сравнивать - на сервере, на каждом сделавшем co/clone (или на _всех_ ;-), на сборочном тазу где svn export вполне бы хватило ?> 2. "история" всегда под "боком"
ну, как и весь репо. Но не факт что это для многих проблема (у кого-то то и другое где-то в сети, и working copy тож)
> 3. механизм diff`ов
ну а тут чего интересного? Вот _не_ с точки зрения каких-то мегапроектов со странными особенностями, а чего-то вроде нашего покойного lighttpd (ну или clang даже) и возникающих там задач?
> звиняйте, но не только лишь все используют гитхаб или gitlab, бывает и свои мощности
> используютну просто пользователи svn уже научилсь не доверять чужим сервисам, на горьком опыте, а пользователи git радостно бегут наступать на уже знакомые грабли.
с точки зрения админа своих мощностей, даже не берусь определить, что противнее админить (многопользовательский и с разделением прав svn в любом своем протоколе та еще головная боль и геморрой, но и гит не лучше - если, конечно, тебе дороги твои пароли и твои пользователи)
> а кто этот доктор поставившей, этот страшный диагноз Линусу - ну там пруфы..
пруфы для опоздавших родиться - в архивах lkml где-то между 99-м (когда все вменяемые люди уже использовали хотя бы cvs,и только великий Торвальдс шел своим путем с ручным прикладыванием миллиарда патчиков и tar.gz архивчиком) и 2002-м (когда из десятка вариантов был выбран самый уродливый, не просто проприетарный а налагающий совершенно безобразные требования на пользователей - но и это было для многих щастьем несказанным). Я, естественно, никому ничего доказывать не собирался и копий его истерик не сохранял.
>> 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Локальный Опыт подтвердил разумность схемы,
Откланяюсь
На самом деле, главный плюс распределенной системы в том, что с svn-ом надо нормальный канал с сервером, а с гитом можно спокойно работать в офлайне или с дерьмовым мобильным интернетом. Скажем, посиживая на берегу моря.Для меня, по крайней мере, главный. Офисному планктону особо без разницы, думаю.
> а с гитом можно спокойно работать в офлайне или с дерьмовым мобильным интернетом.ниасилили терминальный доступ?
> Для меня, по крайней мере, главный. Офисному планктону особо без разницы, думаю.еще бывают клепатели не для себя, любимого.
При этом я-то могу быть и на берегу моря - у меня один хер что на берегу, что в офисе - терминал. Тащить на берег моря то, что может это скомпилировать, мне тяжеловато, а то что может тестировать - вообще только aircargo.
В виду того, что запускать потом все равно надо не на любимом планшетике, а на не совсем даже pc-архитектуре и с нетранспортабельной мощностью. Если у этой штуки отвалится коннективити- у нее будут совсем другие проблемы, про проблему недоступности репозитория уже и вспоминать будет некогда (да и сборка там тоже distributed).линуксописателям - тем да, у них вся жизнь в написании нового ведра чтобы на нем скомпилить еще более новое ведро, и физическую доступность кнопки ресет подавай.
А чтобы начать более менее нормально и комфортно работать, надо будет 2-5 месяцев
Им надо пользоваться, а не работать.
ну если ты админишь локалхост, то да, можно просто пользоваться, а не работать :D
> ну если ты админишь локалхост, то да, можно просто пользоваться, а не
> работать :Dдаже если локалхост - то все равно может понадобится работать - когда нужно не побыстрому clone/make/rm -r, а найти, в какой момент чужой, плохо (или, чаще, никак) документированный проект поехал не в ту степь, выцарапать нужный айдишник и потом попытаться собрать работающую версию. Хотя бы даже работающую лично вот у тебя на локалхосте и один раз.
> ну если ты админишь локалхост, то да, можно просто пользоваться, а не работать :DУ яндекса на лайти довольно серьезный локалхост помнится был - mirror.yandex.ru.
> даже если локалхост - то все равно может понадобится работать - когда нужно не побыстрому clone/make/rm -r, а найти, в какой момент чужой, плохо (или, чаще, никак) документированный проект поехал не в ту степь, выцарапать нужный айдишник и потом попытаться собрать работающую версию. Хотя бы даже работающую лично вот у тебя на локалхосте и один раз.об этом я и говорил, и чтобы это делать на автомате, а не на каждую команду открывать stackoverflow, надо больше 5 дней. Сужу по своему опыту, после 5 лет работы с svn переходить на git было не легко.
> об этом я и говорил, и чтобы это делать на автомате, аНе надо на автомате. Мозг используй.
Чтоб мозг не сопротивлялся, посмотри кинцо с Торавльдсом:
https://www.opennet.ru/openforum/vsluhforumID9/7642.html#3
https://www.opennet.ru/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 просто мучительно болезненны, а искать "в гуглях" вообще нет никакой возможности. Но кого ж волнуют мои трудности, да?
> Сужу по своему опыту, после 5 лет работы с svn переходить на git было не легко.А по моему опыту после ** лет с RCS, CVS и SVN переходить на Git было не только легко и приятно, но ещё и очень быстро. За день перестроил workflow и переписал вспомогательные скрипты (на самом деле, больше выбросил, чем переписал). Потом постепенно перевёл все рабочие проекты на новую систему. О чём это говорит? О том, что личный опыт ни о чём не говорит. Кто-то после автошколы ездит 20 лет и ни одной аварии, а кто-то на первой же практике сносит газетный киоск. Тем не менее, Git сегодня, пожалуй, самый популярный DVCS, а значит он как минимум достаточно прост для освоения.