Redis vs Membase — нет, такого еще не находил, однако Redis vs Memcache есть.
А так как мембаза, это дополнительный обвес к мемкешу, то врядли он будет от этого быстрее.
Результаты этих бенчей, конечно, очень противоречивы, однако…
Лучше самому протестировать. Так как к примеру на Mac OS, Редис, просто тормоз и в виртулке с убунтой на этой же системе, он дает раза в 3-4 лучшие результаты.
Функционал. Функционал это по сути кусок кода. Как вы обмениваетесь именно этими кусками, при этом не обмениваетесь не нужными кусками, попавщие к вам от других участников?
У всех ваших фиче-веток, общий предок? Тогда я понимаю, как можно обмениваться именно куском функционала. В других случаях — нет. Но при этом организация репо должна быть строго иерархической и должны быть правила синхронизации. Вот этот вопрос меня интересует.
Сложно все это на словах, схему надо. Но это важно и интересно.
Не понятно на самом деле как организована работа с кодом. Слить кусок функционала — это как по вашему? Каждый разработчик на основе какой ветки он начинает разработку? Схема не помешала бы.
Суть в том, что если разработчики непрерывно шарят свой код друг с другом, то ИХ функционал содержит, возможно, не отестированный функционал других.
Если же у всего функционала общий предок, скажем релиз ветка и код не шарится постоянно — тогда понятнее, но все же большое количество веток настораживает и говорит о том, что возможны некоторые ошибки, которые повлекут вливание не оттестированого кода.
И как ксати с bookmarks, вы их не используете? Кадеться, что для feature веток, они бы подошли.
Вот не стоит смешивать 2 совершенно разные веши.
Мне теперь не понятно, люди считают, что код ревью прерогатива issue tracker'а или же им не нравится слово ложить
По первому — мне кажеться совершенно обратное. Код ревью, это для повышения качества кода, для обмена опытом, для ревью кода в конце-концов. Т.е это как бы сугубо часть для разработчиков. Нечего сюда мешать кастомеров и менеджеров, которые могут на основе всего этого делать не правильные выводы.
Ну и у такой организации есть приемущество, все ходит вместе с исходниками и все синхронизируется в понятно виде.
Еще, найти вменяемый инструмент для код ревью, который бы был хоро интегрирован в issue tracker — задача не из простых. На удивление мало их, да убоги они.
Я так понимаю, все это у вас отдельные репозитории, а не ветки?
Тогда я не думаю, что это возможно сделать встроенными средствами. Общаться между репами, это к админам.
Такое, как вы заметили, легко делается хуками в меркуриале. Только почему вас смущает это решение? Хуки, это не костыли, а вполне полезные приспособления.
Я их и пытался собрать. У вас вышло?
А так как мембаза, это дополнительный обвес к мемкешу, то врядли он будет от этого быстрее.
www.ruturaj.net/redis-memcached-tokyo-tyrant-mysql-comparison
nosql.mypopescu.com/post/392578627/a-very-specific-benchmark-files-vs-mysql-vs-memcached
systoilet.wordpress.com/2010/08/09/redis-vs-memcached/
axonflux.com/redis-vs-memcache-benchmarks-on-a-realistic-m
Результаты этих бенчей, конечно, очень противоречивы, однако…
Лучше самому протестировать. Так как к примеру на Mac OS, Редис, просто тормоз и в виртулке с убунтой на этой же системе, он дает раза в 3-4 лучшие результаты.
Попробовать стоит, хотя за 2 минуты сбилдать не удалось. Не находит скрипта configure.
У всех ваших фиче-веток, общий предок? Тогда я понимаю, как можно обмениваться именно куском функционала. В других случаях — нет. Но при этом организация репо должна быть строго иерархической и должны быть правила синхронизации. Вот этот вопрос меня интересует.
Сложно все это на словах, схему надо. Но это важно и интересно.
Суть в том, что если разработчики непрерывно шарят свой код друг с другом, то ИХ функционал содержит, возможно, не отестированный функционал других.
Если же у всего функционала общий предок, скажем релиз ветка и код не шарится постоянно — тогда понятнее, но все же большое количество веток настораживает и говорит о том, что возможны некоторые ошибки, которые повлекут вливание не оттестированого кода.
И как ксати с bookmarks, вы их не используете? Кадеться, что для feature веток, они бы подошли.
Эту штуку надо запускать локально, каждому разработчику, персонально.
Мне теперь не понятно, люди считают, что код ревью прерогатива issue tracker'а или же им не нравится слово ложить
По первому — мне кажеться совершенно обратное. Код ревью, это для повышения качества кода, для обмена опытом, для ревью кода в конце-концов. Т.е это как бы сугубо часть для разработчиков. Нечего сюда мешать кастомеров и менеджеров, которые могут на основе всего этого делать не правильные выводы.
Ну и у такой организации есть приемущество, все ходит вместе с исходниками и все синхронизируется в понятно виде.
Еще, найти вменяемый инструмент для код ревью, который бы был хоро интегрирован в issue tracker — задача не из простых. На удивление мало их, да убоги они.
Не только в начале, но и в конце!
Тогда я не думаю, что это возможно сделать встроенными средствами. Общаться между репами, это к админам.
Такое, как вы заметили, легко делается хуками в меркуриале. Только почему вас смущает это решение? Хуки, это не костыли, а вполне полезные приспособления.
А вообще, странный у вас воркфлов, вот и все )
GoogleCode в 3 раза менее функционален/удобен Bitbucket`а, который в 2 раза менее функциональнее/удобнее Github`а.
Мне, как пользователю hg, завидно только наличие у git`а такой плюшки, как GitHub.
Может оно само ее создаст? Так удобнее!
Пустые папки и код приложения вообще никак не связанны. Сокеты и пайпы тоже коммитать было бы хорошо…
В гите есть 150 команд, в меркуриале по умолчанию 10. Цифры примерный!!!
Если хотите функционал пошире — включите необходимое. Большинству не нужно, они не должны путаться, страдать и т.п. от обилия команд.
Кроме того, большинство нужных расширений встроенные, так что вам будет достаточно поделиться с разработчиками куском конфига.
У меня не «из коробки» только 2 расширения.
Спасибо.