Проверить на чем-то более реальном нет возможности, поскольку «привет ООП».
Прирост скорости в 2 раза относительно HHVM в этом синтетическом тесте при таком урезанном функционале PHP не впечатляет, особенно если учесть, что в этом бенче производится ничто иное, как числодробительные операции и копирование блоков памяти в больших циклах, которые прекрасно оптимизирует компилятор gcc, в том числе не выполняя ничего вообще. Это легко заметить, если немного изменить код, чтобы результаты вычисления были где-то использованы. Другими словами, этот двукратный прирост — это заслуга gcc, а не KPHP.
Прироста в 7-9 раз в случае HHVM хватает с головой, при этом остается полноценный набор возможностей PHP уровня 5.5 с ООП и другими плюшками, и можно выполнить любой существующий код без изменений.
На самом деле ребята из команды HHVM уже проходили этот путь и у них в блоге доходчиво объясняется, почему трансляция PHP в C++ — это пройденный этап.
Я думаю тут проблема в совокупности факторов. Во-первых, svn действительно не в курсе, что куда вливалось, для него это просто коммит каких-то изменений. Хотя в последних версиях он в комментариях обозначает, до какой ревизии было влито, но видимо это его не спасает. Плюс разница еще и в способах организации данных хранилища и способах мержа.
Пока апстрим свн-а не отключен, можно все изменения из него подтягивать через git svn rebase, при этом появляются все недостающие коммиты. Правда для этого нужно было делать git svn clone без опции --no-metadata, потому что git svn ищет последнюю подтянутую ревизию в комментариях истории коммитов.
Тут на помощь снова приходят локальные репозитории гита. Разработчик после завершения своей фичи может локально замержить свою ветку в мастер, если в процессе мержа будут проблемы — он сразу об этом узнает. И тут же он проверяет, все ли ок. Если нет — откатывает мерж и правит код, после чего снова мержит. Если код в мастере сильно поменялся за время выполнения задачи — лучше вообще сделать rebase относительно головы мастера, чтобы код гарантированно ничего не сломал после мержа в мастер, но это только если над фичей работает один человек. При этом все эти изменения происходят локально на машине разработчика, он никому не мешает, пока доводит все до ума.
В результате всего этого разработчик в конечном итоге коммитит исправление в свою ветку, которое позволяет безболезненно замержить потом его ветку в мастер. Сам разработчик мержить в удаленный мастер не может, это порезано на уровне прав доступа к центральному репозиторию. Для этого есть техлид или другое доверенное лицо, ответственное за то, что будет вылито на продакшн.
При этом в истории мастера мы видим чистые мержи фичи1, фичи2 и т.д., без коммитов вида «правка фичи2, чтобы она работала с фичей1».
Решает ровно до тех пор, пока эту ветку не надо будет окончательно тестить и вливать в транк, о чем я уже выше писал. Вот тогда и почувствуется разница между SVN и Git.
И, да, к первому пункту я забыл добавить, что если оба разработчика живут под линуксом и у них настроена авторизация на компы друг друга, то возможно прямое подключение между двумя локальными репозиториями, в этом случае один будет удаленной копией для второго, и они могут взаимодействовать полностью локально, без необходимости частого пуша на сервер. И когда фича будет завершена, можно отредактировать историю, объединив, например, 100 коммитов с пустыми комментариями в 10-20 осмысленных, если конечно в этом будет необходимость. Ведь философия Git — коммить как можно чаще, чтобы в любой момент можно было вернуться к предыдущему микросостоянию, ведь именно для этого и нужна система контроля версий.
За то недолгое время, как мы переехали на Git и добили раз и навсегда master до рабочего состояния, у меня еще ни разу не возникало мысли «сейчас нельзя задеплоить на продакшн, потому что...». Потому что причины больше нет. В мастере всегда рабочий код. А работа по разработке новых фич кипит пуще прежнего.
1. Программист коммитит в свою ветку, пушит на сервер, верстальщик подключает себе эту ветку, сливает в локальную копию, и теперь они вместе работают в ветке фичи, попеременно коммитят и пушат в эту ветку, не затрагивая транк. Задача может выполняться неделями, ведь они никому не мешают, и одновременно взаимодействуют друг с другом, при этом нет никаких ожиданий и простоев.
2. Программист внес изменения в 10 файлов, закоммитил в транк, чтобы у верстальщика работал тот функционал, для которого нужно сделать верстку. Добавим сюда, что программист не один, например их десять. Часть взаимодействует друг с другом, часть с верстальщиками. И все они закоммитили частично нерабочий код, чтобы напарник мог сделать свою часть. Теперь нужно срочно исправить баг. Начинать в логе судорожно искать коммиты, которые они сделали, проходить по кругу и делать опрос, у кого что работает, а что нет, поверить на слово не проверив, отменить изменения в сотнях файлов, при этом не ошибившись ни в одной строчке, чтобы внести на продакшн небольшое исправление, чтобы потом снова вернуть все назад? Это очень удобно)
Объясню на примере. Например, программисту в процессе выполнения задачи нужна верстка какого-то блока. Чтобы передать работу верстальщику, ему нужно закоммитить частично рабочий код (ведь задача не закончена) в транк, чтобы его увидел верстальщик и мог что-то сделать. Внимание! С этого момента в транке находится частично работающий код.
Верстальщик может быть сейчас занят другой задачей либо выполнение необходимых правок требует значительного времени (дни). Теперь представим ситуацию, что другой программист в это время закончил выполнение задачи, его работа проверена и должна быть вылита на продакшн. Прямо сейчас. Либо же на продакшене был обнаружен критический баг, который требует немедленного исправления. А транк поломан, деплоить нельзя. Что делать?
Ключевая разница в том, что в SVN, чтобы проверить работоспособность фичи в ветке в последних актуальных условиях (голова транка), нужно либо замержить ветку в транк, что в нашем случае не вариант, либо замержить транк в ветку, проверить работоспособность, после чего слияние с транком будет _очень_ болезненным, потому что теперь все изменения транка с момента создания ветки будут самостоятельными изменениями ветки, и в момент слияния ветки фичи с транком мы получим целую кучу конфликтов, потому что одни и те же файлы в тех же местах одновременно менялись и в ветке, и в транке.
Рассматривали, но каких-то значительных преимуществ против git для нас не нашли. А поскольку большая часть разработчиков так или иначе уже имела дело с гитом раньше, то выбор стал очевиден.
В том-то и дело, что этот ключ по тому пути больше не нужен. При запуске gitolite setup он этот ключ перекладывает себе в keydir/. Поэтому сразу после setup этот файл вообще можно удалить.
Потому что в будущем планируем постепенно все проекты переводить на git, а у нас их порядка сотни. Плюс у каждого еще свои svn:externals, которые тоже превращаются в отдельные репы. При таком количестве репозиториев стоимость размещения на стороне растет экспоненциально. К тому же локальный сервер для разработки все равно есть, зачем ему простаивать.
В один прекрасный день при включении компа BIOS просто не увидит диск, и больше не увидит никогда. Данные в ячейках флеша останутся, да. Правда толку от этого мало, поскольку внутренняя организация данных на SSD у каждого производителя своя и держится в тайне, и шансов, что какой-то сервис восстановит данные — около 0.0001%. Большинство просто не возьмутся за работу, которая не осуществима.
Почитайте профильные форумы с многочисленными криками «АААА! он умер», особенно подобными отзывами славится продукция OCZ, хотя у других производителей тоже бывает.
Скорее всего, умерший SSD поменяют по гарантии, но данные при этом будут потеряны навсегда.
KPHP: 0.118HHVM 2.5: 0.271PHP 5.5.9: 1.982PHP 5.3.28: 2.524Проверить на чем-то более реальном нет возможности, поскольку «привет ООП».
Прирост скорости в 2 раза относительно HHVM в этом синтетическом тесте при таком урезанном функционале PHP не впечатляет, особенно если учесть, что в этом бенче производится ничто иное, как числодробительные операции и копирование блоков памяти в больших циклах, которые прекрасно оптимизирует компилятор gcc, в том числе не выполняя ничего вообще. Это легко заметить, если немного изменить код, чтобы результаты вычисления были где-то использованы. Другими словами, этот двукратный прирост — это заслуга gcc, а не KPHP.
Прироста в 7-9 раз в случае HHVM хватает с головой, при этом остается полноценный набор возможностей PHP уровня 5.5 с ООП и другими плюшками, и можно выполнить любой существующий код без изменений.
На самом деле ребята из команды HHVM уже проходили этот путь и у них в блоге доходчиво объясняется, почему трансляция PHP в C++ — это пройденный этап.
git svn rebase, при этом появляются все недостающие коммиты. Правда для этого нужно было делатьgit svn cloneбез опции --no-metadata, потому что git svn ищет последнюю подтянутую ревизию в комментариях истории коммитов.В результате всего этого разработчик в конечном итоге коммитит исправление в свою ветку, которое позволяет безболезненно замержить потом его ветку в мастер. Сам разработчик мержить в удаленный мастер не может, это порезано на уровне прав доступа к центральному репозиторию. Для этого есть техлид или другое доверенное лицо, ответственное за то, что будет вылито на продакшн.
При этом в истории мастера мы видим чистые мержи фичи1, фичи2 и т.д., без коммитов вида «правка фичи2, чтобы она работала с фичей1».
И, да, к первому пункту я забыл добавить, что если оба разработчика живут под линуксом и у них настроена авторизация на компы друг друга, то возможно прямое подключение между двумя локальными репозиториями, в этом случае один будет удаленной копией для второго, и они могут взаимодействовать полностью локально, без необходимости частого пуша на сервер. И когда фича будет завершена, можно отредактировать историю, объединив, например, 100 коммитов с пустыми комментариями в 10-20 осмысленных, если конечно в этом будет необходимость. Ведь философия Git — коммить как можно чаще, чтобы в любой момент можно было вернуться к предыдущему микросостоянию, ведь именно для этого и нужна система контроля версий.
За то недолгое время, как мы переехали на Git и добили раз и навсегда master до рабочего состояния, у меня еще ни разу не возникало мысли «сейчас нельзя задеплоить на продакшн, потому что...». Потому что причины больше нет. В мастере всегда рабочий код. А работа по разработке новых фич кипит пуще прежнего.
2. Программист внес изменения в 10 файлов, закоммитил в транк, чтобы у верстальщика работал тот функционал, для которого нужно сделать верстку. Добавим сюда, что программист не один, например их десять. Часть взаимодействует друг с другом, часть с верстальщиками. И все они закоммитили частично нерабочий код, чтобы напарник мог сделать свою часть. Теперь нужно срочно исправить баг. Начинать в логе судорожно искать коммиты, которые они сделали, проходить по кругу и делать опрос, у кого что работает, а что нет, поверить на слово не проверив, отменить изменения в сотнях файлов, при этом не ошибившись ни в одной строчке, чтобы внести на продакшн небольшое исправление, чтобы потом снова вернуть все назад? Это очень удобно)
Верстальщик может быть сейчас занят другой задачей либо выполнение необходимых правок требует значительного времени (дни). Теперь представим ситуацию, что другой программист в это время закончил выполнение задачи, его работа проверена и должна быть вылита на продакшн. Прямо сейчас. Либо же на продакшене был обнаружен критический баг, который требует немедленного исправления. А транк поломан, деплоить нельзя. Что делать?
Обновление локальной копии и подтягивание в redmine производится по крону с некоторой периодичностью, пока этого хватает.
B — 2011
5 — май, 6 — июнь…
В один прекрасный день при включении компа BIOS просто не увидит диск, и больше не увидит никогда. Данные в ячейках флеша останутся, да. Правда толку от этого мало, поскольку внутренняя организация данных на SSD у каждого производителя своя и держится в тайне, и шансов, что какой-то сервис восстановит данные — около 0.0001%. Большинство просто не возьмутся за работу, которая не осуществима.
Почитайте профильные форумы с многочисленными криками «АААА! он умер», особенно подобными отзывами славится продукция OCZ, хотя у других производителей тоже бывает.
Скорее всего, умерший SSD поменяют по гарантии, но данные при этом будут потеряны навсегда.