Это плодит ненужные сущности. Очень круто, когда у меня есть радио под мое настроение, но оно нужно мне прямо сейчас и будет не нужно завтра. А у вас там куча всего под него создается, еще этот UUID в урле, наверняка в базе что-то есть :). А время жизни у такого плей-листа в большинстве случаев — это от получаса до нескольких часов. Если он пропадет, да и фиг с ним, снова сгенерирую.
Я это к тому, что скорей всего для всех, кроме создателей, такие одноразовые плейлисты — это мусор.
Мне очень нравилось на last.fm радио по произвольному тэгу или исполнителю. У вас есть похожий функционал — создать плейлист по треку, но это немного не то. Я не хочу ничего создавать, я хочу радио.
У них две конструктивных особенности, которые сильно облегчают жизнь:
* широкая крышка, которая надевается гораздо легче
* основание короба имеет узкую щель. Даже без крышки ваши провода не выпадут, что сильно помогает монтажу.
Да, мне тоже нравятся короткие итерации, но увы это не всегда получается. Иногда надо существенно изменить продукт, при этом изменения должны уйти на прод только целиком.
git co -b branchName branchName && git svn rebase && git merge --log --no-ff master && git svn dcommit
Обратно — аналогично.
svn такие мержи не понимает, это да. Поэтому я и говорю, что мержить должен кто-то один. Если начали мержить гитом, то до вливания в master (trunk) нужно продолжать мержить им же.
>Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
У нас одна команда разработки, т.е. описанные проблемы нас не коснулись.
Единственное о чем я писал выше — мержить должен кто-то один. Или средствами svn или средствами git. В нашей уютненькой компании — это совершенно не проблема.
Нашего опыта явно недостаточно чтобы подтвердить наличие проблем. При этом я нисколько не сомневаюсь, что они есть и при использовании инструмент следует их учитывать.
Если бы мы выбирали сейчас, то точно выбрали бы git.
git-svn — это решение, которое позволяет ничего не менять для тех, кто менять ничего не хочет, но при этом использовать плюсы git тем, кто в них нуждается.
Имейте ввиду, что когда часть команды работает в svn, а часть через git-svn, то мержить должен кто-то один.
Если вы сделаете мерж из master в бранч средствами svn, а через некоторое время средствами git-svn, то почти гарантированно получите пачку странных конфликтов.
> разве там git не будет с ума сходить если к этим веткам надо как-то обратиться?
ИМХО если origin у вас один, то ничего страшного в одинаковом названии нет, т.к. нет конфликта.
Если originов несколько, то надо давать префиксы, чтобы понять с какого именно origin был снят local branch.
Это ИМХО, скорее вопрос религии как и codingStyle.
1. Согласен с коллегой. ИМХО обращаться к удаленной (remote) ветке нужно только при pull/push (dcommit), причем указывать ее явно. Это защитит от «коммитов не туда».
2. --no-ff нужно добавлять всегда, когда мержишь в master и работаешь с git-svn. При мерже из мастера в бранч он не нужен.
Про саму идею fast-forward вон здесь хорошо написано. habrahabr.ru/post/136847/
Где должны отображаться «виджеты»?
У нас отмечены все чекбоксы «отображать на сайте», но я не вижу ни одного из них по этой ссылке habrahabr.ru/company/wapstart/
btw и вакансии с хантим.ру куда-то пропали, раньше они были в «шапке».
В представляете сколько будет ожидать приложение подключения к упавшему серверу кеширования
прежде чем отвалится по timeout-у? Это только увеличит время получения данных а не уменьшит его.
У нас мемкеши — это не только кеширующая подсистема, но и система хранения.
Т.е. если данных нет в кеше, то приложение считает, что их нет вообще.
Приложение будет ждать столько времени, сколько мы указали в конструкторе PeclMemcache. Я вон тут писал, что сейчас можно использовать float в качестве timeout
Фреймворк не должен писаться под конкретную задачу.
Вы неправильно меня поняли. Фраза начиналась со слов «в последнее время». Это важно.
В противном случае, Вы можете внести изменения в фреймворк, которые сделают его не применимым для некого рода других «конкретных» задач.
Поэтому у нашей компании есть свой форк, который слегка отличается от master. github.com/WapStart/onphp-framework/
Код общего назначения мы сливаем в него. Иногда он попадает в мастер, а иногда сообщество его не принимает. По похожим причинам, кстати :)
Для чего?
У нас нет открытого issue по поводу «некрасивости» Timestamp. Как только его заведет кто-нибудь из пользователей фреймворка, мы обязательно предложим решение.
Это я уже нашел :)
Это плодит ненужные сущности. Очень круто, когда у меня есть радио под мое настроение, но оно нужно мне прямо сейчас и будет не нужно завтра. А у вас там куча всего под него создается, еще этот UUID в урле, наверняка в базе что-то есть :). А время жизни у такого плей-листа в большинстве случаев — это от получаса до нескольких часов. Если он пропадет, да и фиг с ним, снова сгенерирую.
Я это к тому, что скорей всего для всех, кроме создателей, такие одноразовые плейлисты — это мусор.
Есть в планах что-то подобное?
У них две конструктивных особенности, которые сильно облегчают жизнь:
* широкая крышка, которая надевается гораздо легче
* основание короба имеет узкую щель. Даже без крышки ваши провода не выпадут, что сильно помогает монтажу.
У нас вот как-то не получается делать параллельную разработку так, чтобы конфликтов не было вообще.
Это не тяжелая процедура.
У нас вроде бы кто-то даже git svn fetch в крон ставил на нерабочее по всем проектам.
Обратно — аналогично.
svn такие мержи не понимает, это да. Поэтому я и говорю, что мержить должен кто-то один. Если начали мержить гитом, то до вливания в master (trunk) нужно продолжать мержить им же.
У нас одна команда разработки, т.е. описанные проблемы нас не коснулись.
Единственное о чем я писал выше — мержить должен кто-то один. Или средствами svn или средствами git. В нашей уютненькой компании — это совершенно не проблема.
Нашего опыта явно недостаточно чтобы подтвердить наличие проблем. При этом я нисколько не сомневаюсь, что они есть и при использовании инструмент следует их учитывать.
git-svn — это решение, которое позволяет ничего не менять для тех, кто менять ничего не хочет, но при этом использовать плюсы git тем, кто в них нуждается.
По поводу объема:
Ревизий почти 90 000.
Главное дождаться первого fetch, потом всё будет быстро.
Если вы сделаете мерж из master в бранч средствами svn, а через некоторое время средствами git-svn, то почти гарантированно получите пачку странных конфликтов.
Удачи в переходе ;)
ИМХО если origin у вас один, то ничего страшного в одинаковом названии нет, т.к. нет конфликта.
Если originов несколько, то надо давать префиксы, чтобы понять с какого именно origin был снят local branch.
Это ИМХО, скорее вопрос религии как и codingStyle.
2. --no-ff нужно добавлять всегда, когда мержишь в master и работаешь с git-svn. При мерже из мастера в бранч он не нужен.
Про саму идею fast-forward вон здесь хорошо написано. habrahabr.ru/post/136847/
Хе, нашел хабрабаг.
У нас отмечены все чекбоксы «отображать на сайте», но я не вижу ни одного из них по этой ссылке habrahabr.ru/company/wapstart/
btw и вакансии с хантим.ру куда-то пропали, раньше они были в «шапке».
У нас мемкеши — это не только кеширующая подсистема, но и система хранения.
Т.е. если данных нет в кеше, то приложение считает, что их нет вообще.
Приложение будет ждать столько времени, сколько мы указали в конструкторе PeclMemcache. Я вон тут писал, что сейчас можно использовать float в качестве timeout
Спасибо. )
По теме — ваша идея понятна. Обсудим в рассылке.
Вы неправильно меня поняли. Фраза начиналась со слов «в последнее время». Это важно.
Поэтому у нашей компании есть свой форк, который слегка отличается от master. github.com/WapStart/onphp-framework/
Код общего назначения мы сливаем в него. Иногда он попадает в мастер, а иногда сообщество его не принимает. По похожим причинам, кстати :)
У нас нет открытого issue по поводу «некрасивости» Timestamp. Как только его заведет кто-нибудь из пользователей фреймворка, мы обязательно предложим решение.